發表日期:2018-03 文章編輯:小燈 瀏覽次數:2745
轉自:【HTTP】HTTPS 原理詳解
HTTPS(全稱:HyperText Transfer Protocol over Secure Socket Layer),其實 HTTPS 并不是一個新鮮協議,Google 很早就開始啟用了,初衷是為了保證數據安全。 近兩年,Google、Baidu、Facebook 等這樣的互聯網巨頭,不謀而合地開始大力推行 HTTPS, 國內外的大型互聯網公司很多也都已經啟用了全站 HTTPS,這也是未來互聯網發展的趨勢。
為鼓勵全球網站的 HTTPS 實現,一些互聯網公司都提出了自己的要求:
1)Google 已調整搜索引擎算法,讓采用 HTTPS 的網站在搜索中排名更靠前;
2)從 2017 年開始,Chrome 瀏覽器已把采用 HTTP 協議的網站標記為不安全網站;
3)蘋果要求 2017 年App Store 中的所有應用都必須使用 HTTPS 加密連接;
4)當前國內炒的很火熱的微信小程序也要求必須使用 HTTPS 協議;
5)新一代的 HTTP/2 協議的支持需以 HTTPS 為基礎。
等等,因此想必在不久的將來,全網 HTTPS 勢在必行。
概念
協議
1、HTTP 協議(HyperText Transfer Protocol,超文本傳輸協議):是客戶端瀏覽器或其他程序與Web服務器之間的應用層通信協議 。
2、HTTPS 協議(HyperText Transfer Protocol over Secure Socket Layer):可以理解為HTTP+SSL/TLS, 即 HTTP 下加入 SSL 層,HTTPS 的安全基礎是 SSL,因此加密的詳細內容就需要 SSL,用于安全的 HTTP 數據傳輸。
如上圖所示 HTTPS 相比 HTTP 多了一層 SSL/TLS
SSL(Secure Socket Layer,安全套接字層):1994年為 Netscape 所研發,SSL 協議位于 TCP/IP 協議與各種應用層協議之間,為數據通訊提供安全支持。
TLS(Transport Layer Security,傳輸層安全):其前身是 SSL,它最初的幾個版本(SSL 1.0、SSL 2.0、SSL 3.0)由網景公司開發,1999年從 3.1 開始被 IETF 標準化并改名,發展至今已經有 TLS 1.0、TLS 1.1、TLS 1.2 三個版本。SSL3.0和TLS1.0由于存在安全漏洞,已經很少被使用到。TLS 1.3 改動會比較大,目前還在草案階段,目前使用最廣泛的是TLS 1.1、TLS 1.2。
加密算法:
據記載,公元前400年,古希臘人就發明了置換密碼;在第二次世界大戰期間,德國軍方啟用了“恩尼格瑪”密碼機,所以密碼學在社會發展中有著廣泛的用途。
1、對稱加密
有流式、分組兩種,加密和解密都是使用的同一個密鑰。
例如:DES、AES-GCM、ChaCha20-Poly1305等
2、非對稱加密
加密使用的密鑰和解密使用的密鑰是不相同的,分別稱為:公鑰、私鑰,公鑰和算法都是公開的,私鑰是保密的。非對稱加密算法性能較低,但是安全性超強,由于其加密特性,非對稱加密算法能加密的數據長度也是有限的。
例如:RSA、DSA、ECDSA、 DH、ECDHE
3、哈希算法
將任意長度的信息轉換為較短的固定長度的值,通常其長度要比信息小得多,且算法不可逆。
例如:MD5、SHA-1、SHA-2、SHA-256 等
4、數字簽名
簽名就是在信息的后面再加上一段內容(信息經過hash后的值),可以證明信息沒有被修改過。hash值一般都會加密后(也就是簽名)再和信息一起發送,以保證這個hash值不被修改。
詳解
一、HTTP訪問過程
抓包如下:
如上圖所示,HTTP請求過程中,客戶端與服務器之間沒有任何身份確認的過程,數據全部明文傳輸,“裸奔”在互聯網上,所以很容易遭到黑客的攻擊,如下:
可以看到,客戶端發出的請求很容易被黑客截獲,如果此時黑客冒充服務器,則其可返回任意信息給客戶端,而不被客戶端察覺,所以我們經常會聽到一詞“劫持”,現象如下:
下面兩圖中,瀏覽器中填入的是相同的URL,左邊是正確響應,而右邊則是被劫持后的響應
所以 HTTP 傳輸面臨的風險有:
(1) 竊聽風險:黑客可以獲知通信內容。
(2) 篡改風險:黑客可以修改通信內容。
(3) 冒充風險:黑客可以冒充他人身份參與通信。
二、HTTP 向 HTTPS 演化的過程
第一步:為了防止上述現象的發生,人們想到一個辦法:對傳輸的信息加密(即使黑客截獲,也無法破解)
如上圖所示,此種方式屬于對稱加密,雙方擁有相同的密鑰,信息得到安全傳輸,但此種方式的缺點是:
(1)不同的客戶端、服務器數量龐大,所以雙方都需要維護大量的密鑰,維護成本很高
(2)因每個客戶端、服務器的安全級別不同,密鑰極易泄露
第二步:既然使用對稱加密時,密鑰維護這么繁瑣,那我們就用非對稱加密試試
如上圖所示,客戶端用公鑰對請求內容加密,服務器使用私鑰對內容解密,反之亦然,但上述過程也存在缺點:
(1)公鑰是公開的(也就是黑客也會有公鑰),所以第 ④ 步私鑰加密的信息,如果被黑客截獲,其可以使用公鑰進行解密,獲取其中的內容
第三步:非對稱加密既然也有缺陷,那我們就將對稱加密,非對稱加密兩者結合起來,取其精華、去其糟粕,發揮兩者的各自的優勢
如上圖所示
(1)第 ③ 步時,客戶端說:(咱們后續回話采用對稱加密吧,這是對稱加密的算法和對稱密鑰)這段話用公鑰進行加密,然后傳給服務器
(2)服務器收到信息后,用私鑰解密,提取出對稱加密算法和對稱密鑰后,服務器說:(好的)對稱密鑰加密
(3)后續兩者之間信息的傳輸就可以使用對稱加密的方式了
遇到的問題:
(1)客戶端如何獲得公鑰
(2)如何確認服務器是真實的而不是黑客
第四步:獲取公鑰與確認服務器身份
1、獲取公鑰
(1)提供一個下載公鑰的地址,回話前讓客戶端去下載。(缺點:下載地址有可能是假的;客戶端每次在回話前都先去下載公鑰也很麻煩)
(2)回話開始時,服務器把公鑰發給客戶端(缺點:黑客冒充服務器,發送給客戶端假的公鑰)
2、那有木有一種方式既可以安全的獲取公鑰,又能防止黑客冒充呢? 那就需要用到終極武器了:SSL 證書(申購)
如上圖所示,在第 ② 步時服務器發送了一個SSL證書給客戶端,SSL 證書中包含的具體內容有:
(1)證書的發布機構CA
(2)證書的有效期
(3)公鑰
(4)證書所有者
(5)簽名
………
3、客戶端在接受到服務端發來的SSL證書時,會對證書的真偽進行校驗,以瀏覽器為例說明如下:
(1)首先瀏覽器讀取證書中的證書所有者、有效期等信息進行一一校驗
(2)瀏覽器開始查找操作系統中已內置的受信任的證書發布機構CA,與服務器發來的證書中的頒發者CA比對,用于校驗證書是否為合法機構頒發
(3)如果找不到,瀏覽器就會報錯,說明服務器發來的證書是不可信任的。
(4)如果找到,那么瀏覽器就會從操作系統中取出 頒發者CA 的公鑰,然后對服務器發來的證書里面的簽名進行解密
(5)瀏覽器使用相同的hash算法計算出服務器發來的證書的hash值,將這個計算的hash值與證書中簽名做對比
(6)對比結果一致,則證明服務器發來的證書合法,沒有被冒充
(7)此時瀏覽器就可以讀取證書中的公鑰,用于后續加密了
4、所以通過發送SSL證書的形式,既解決了公鑰獲取問題,又解決了黑客冒充問題,一箭雙雕,HTTPS加密過程也就此形成
所以相比HTTP,HTTPS 傳輸更加安全
(1) 所有信息都是加密傳播,黑客無法竊聽。
(2) 具有校驗機制,一旦被篡改,通信雙方會立刻發現。
(3) 配備身份證書,防止身份被冒充。
總結
綜上所述,相比 HTTP 協議,HTTPS 協議增加了很多握手、加密解密等流程,雖然過程很復雜,但其可以保證數據傳輸的安全。所以在這個互聯網膨脹的時代,其中隱藏著各種看不見的危機,為了保證數據的安全,維護網絡穩定,建議大家多多推廣HTTPS。
HTTPS 缺點:
(1)SSL 證書費用很高,以及其在服務器上的部署、更新維護非常繁瑣
(2)HTTPS 降低用戶訪問速度(多次握手)
(3)網站改用HTTPS 以后,由HTTP 跳轉到 HTTPS 的方式增加了用戶訪問耗時(多數網站采用302跳轉)
(4)HTTPS 涉及到的安全算法會消耗 CPU 資源,需要增加大量機器(https訪問過程需要加解密)
package com.supersoft.zhuanzhuan.utils;
import java.io.IOException;
import java.nio.charset.Charset;
import java.security.KeyManagementException;
import java.security.KeyStoreException;
import java.security.NoSuchAlgorithmException;
import java.security.cert.X509Certificate;
import java.util.ArrayList;
import java.util.List;
import java.util.Map;
import java.util.logging.Level;
import java.util.logging.Logger;
import javax.net.ssl.SSLContext;
import org.apache.http.HttpEntity;
import org.apache.http.NameValuePair;
import org.apache.http.client.entity.UrlEncodedFormEntity;
import org.apache.http.client.methods.CloseableHttpResponse;
import org.apache.http.client.methods.HttpGet;
import org.apache.http.client.methods.HttpPost;
import org.apache.http.conn.ssl.SSLConnectionSocketFactory;
import org.apache.http.conn.ssl.SSLContextBuilder;
import org.apache.http.conn.ssl.TrustStrategy;
import org.apache.http.impl.client.CloseableHttpClient;
import org.apache.http.impl.client.HttpClients;
import org.apache.http.message.BasicNameValuePair;
import org.apache.http.util.EntityUtils;
/**
**/
public class HttpUtil {
public static final String get(final String url, final Map<String, Object> params) { StringBuilder sb = new StringBuilder("");if (null != params && !params.isEmpty()) { int i = 0; for (String key : params.keySet()) { if (i == 0) { sb.append("?"); } else { sb.append("&"); } sb.append(key).append("=").append(params.get(key)); i++; } }CloseableHttpClient httpClient = createSSLClientDefault();CloseableHttpResponse response = null; HttpGet get = new HttpGet(url + sb.toString()); String result = "";try { response = httpClient.execute(get);if (response.getStatusLine().getStatusCode() == 200) { HttpEntity entity = response.getEntity(); if (null != entity) { result = EntityUtils.toString(entity, "UTF-8"); } } } catch (IOException ex) { Logger.getLogger(HttpUtil.class.getName()).log(Level.SEVERE, null, ex); } finally { if (null != response) { try { EntityUtils.consume(response.getEntity()); } catch (IOException ex) { Logger.getLogger(HttpUtil.class.getName()).log(Level.SEVERE, null, ex); } } }return result; }public static final String post(final String url, final Map<String, Object> params) { CloseableHttpClient httpClient = createSSLClientDefault(); HttpPost post = new HttpPost(url);CloseableHttpResponse response = null;if (null != params && !params.isEmpty()) { List<NameValuePair> nvpList = new ArrayList<NameValuePair>(); for (Map.Entry<String, Object> entry : params.entrySet()) { NameValuePair nvp = new BasicNameValuePair(entry.getKey(), entry.getValue().toString()); nvpList.add(nvp); } post.setEntity(new UrlEncodedFormEntity(nvpList, Charset.forName("UTF-8"))); }String result = "";try { response = httpClient.execute(post);if (response.getStatusLine().getStatusCode() == 200) { HttpEntity entity = response.getEntity(); if (null != entity) { result = EntityUtils.toString(entity, "UTF-8"); } } } catch (IOException ex) { Logger.getLogger(HttpUtil.class.getName()).log(Level.SEVERE, null, ex); } finally { if (null != response) { try { EntityUtils.consume(response.getEntity()); } catch (IOException ex) { Logger.getLogger(HttpUtil.class.getName()).log(Level.SEVERE, null, ex); } } }return result; }private static CloseableHttpClient createSSLClientDefault() {SSLContext sslContext; try { sslContext = new SSLContextBuilder().loadTrustMaterial(null, new TrustStrategy() { // 信任所有 @Override public boolean isTrusted(X509Certificate[] xcs, String string) { return true; } }).build();SSLConnectionSocketFactory sslsf = new SSLConnectionSocketFactory(sslContext);return HttpClients.custom().setSSLSocketFactory(sslsf).build(); } catch (KeyStoreException ex) { Logger.getLogger(HttpUtil.class.getName()).log(Level.SEVERE, null, ex); } catch (NoSuchAlgorithmException ex) { Logger.getLogger(HttpUtil.class.getName()).log(Level.SEVERE, null, ex); } catch (KeyManagementException ex) { Logger.getLogger(HttpUtil.class.getName()).log(Level.SEVERE, null, ex); }return HttpClients.createDefault(); }public static void main(String[] args) { System.out.println("Result:" + get("https://kyfw.12306.cn/otn/resources/js/framework/station_name.js", null)); }
}
日期:2018-04 瀏覽次數:6990
日期:2017-02 瀏覽次數:3686
日期:2017-09 瀏覽次數:3963
日期:2017-12 瀏覽次數:3768
日期:2018-12 瀏覽次數:5108
日期:2016-12 瀏覽次數:4809
日期:2017-07 瀏覽次數:13872
日期:2017-12 瀏覽次數:3736
日期:2018-06 瀏覽次數:4486
日期:2018-05 瀏覽次數:4672
日期:2017-12 瀏覽次數:3767
日期:2017-06 瀏覽次數:4184
日期:2018-01 瀏覽次數:4174
日期:2016-12 瀏覽次數:4134
日期:2018-08 瀏覽次數:4618
日期:2017-12 瀏覽次數:3979
日期:2016-09 瀏覽次數:6733
日期:2018-07 瀏覽次數:3412
日期:2016-12 瀏覽次數:3448
日期:2018-10 瀏覽次數:3589
日期:2018-10 瀏覽次數:3703
日期:2018-09 瀏覽次數:3812
日期:2018-02 瀏覽次數:3824
日期:2015-05 瀏覽次數:3731
日期:2018-09 瀏覽次數:3511
日期:2018-06 瀏覽次數:3635
日期:2017-02 瀏覽次數:4079
日期:2018-02 瀏覽次數:4579
日期:2018-02 瀏覽次數:4441
日期:2016-12 瀏覽次數:3775
Copyright ? 2013-2018 Tadeng NetWork Technology Co., LTD. All Rights Reserved.