轉(zhuǎn)自：【HTTP】HTTPS 原理詳解
一、HTTPS原理
HTTPS（全稱(chēng)：HyperText Transfer Protocol over Secure Socket Layer）渣淤，其實(shí) HTTPS 并不是一個(gè)新鮮協(xié)議鲫惶，Google 很早就開(kāi)始啟用了邻辉，初衷是為了保證數(shù)據(jù)安全猿棉。 近兩年节吮，Google银舱、Baidu瘪匿、Facebook 等這樣的互聯(lián)網(wǎng)巨頭，不謀而合地開(kāi)始大力推行 HTTPS寻馏， 國(guó)內(nèi)外的大型互聯(lián)網(wǎng)公司很多也都已經(jīng)啟用了全站 HTTPS棋弥，這也是未來(lái)互聯(lián)網(wǎng)發(fā)展的趨勢(shì)。
為鼓勵(lì)全球網(wǎng)站的 HTTPS 實(shí)現(xiàn)诚欠，一些互聯(lián)網(wǎng)公司都提出了自己的要求：
1）Google 已調(diào)整搜索引擎算法顽染，讓采用 HTTPS 的網(wǎng)站在搜索中排名更靠前；
2）從 2017 年開(kāi)始聂薪，Chrome 瀏覽器已把采用 HTTP 協(xié)議的網(wǎng)站標(biāo)記為不安全網(wǎng)站家乘；
3）蘋(píng)果要求 2017 年App Store 中的所有應(yīng)用都必須使用 HTTPS 加密連接；
4）當(dāng)前國(guó)內(nèi)炒的很火熱的微信小程序也要求必須使用 HTTPS 協(xié)議藏澳；
5）新一代的 HTTP/2 協(xié)議的支持需以 HTTPS 為基礎(chǔ)仁锯。
等等，因此想必在不久的將來(lái)翔悠，全網(wǎng) HTTPS 勢(shì)在必行业崖。
概念
協(xié)議
1、HTTP 協(xié)議（HyperText Transfer Protocol蓄愁，超文本傳輸協(xié)議）：是客戶端瀏覽器或其他程序與Web服務(wù)器之間的應(yīng)用層通信協(xié)議 双炕。
2、HTTPS 協(xié)議（HyperText Transfer Protocol over Secure Socket Layer）：可以理解為HTTP+SSL/TLS撮抓， 即 HTTP 下加入 SSL 層妇斤，HTTPS 的安全基礎(chǔ)是 SSL，因此加密的詳細(xì)內(nèi)容就需要 SSL丹拯，用于安全的 HTTP 數(shù)據(jù)傳輸站超。
如上圖所示 HTTPS 相比 HTTP 多了一層 SSL/TLS
SSL（Secure Socket Layer，安全套接字層）：1994年為 Netscape 所研發(fā)乖酬，SSL 協(xié)議位于 TCP/IP 協(xié)議與各種應(yīng)用層協(xié)議之間死相，為數(shù)據(jù)通訊提供安全支持。
TLS（Transport Layer Security咬像，傳輸層安全）：其前身是 SSL算撮，它最初的幾個(gè)版本（SSL 1.0生宛、SSL 2.0、SSL 3.0）由網(wǎng)景公司開(kāi)發(fā)肮柜，1999年從 3.1 開(kāi)始被 IETF 標(biāo)準(zhǔn)化并改名陷舅，發(fā)展至今已經(jīng)有 TLS 1.0、TLS 1.1素挽、TLS 1.2 三個(gè)版本蔑赘。SSL3.0和TLS1.0由于存在安全漏洞，已經(jīng)很少被使用到预明。TLS 1.3 改動(dòng)會(huì)比較大缩赛，目前還在草案階段，目前使用最廣泛的是TLS 1.1撰糠、TLS 1.2酥馍。
加密算法：
據(jù)記載，公元前400年阅酪，古希臘人就發(fā)明了置換密碼旨袒；在第二次世界大戰(zhàn)期間，德國(guó)軍方啟用了“恩尼格瑪”密碼機(jī)术辐，所以密碼學(xué)在社會(huì)發(fā)展中有著廣泛的用途砚尽。
1、對(duì)稱(chēng)加密
有流式辉词、分組兩種必孤，加密和解密都是使用的同一個(gè)密鑰。
例如：DES瑞躺、AES-GCM敷搪、ChaCha20-Poly1305等
2、非對(duì)稱(chēng)加密
加密使用的密鑰和解密使用的密鑰是不相同的幢哨，分別稱(chēng)為：公鑰赡勘、私鑰，公鑰和算法都是公開(kāi)的捞镰，私鑰是保密的闸与。非對(duì)稱(chēng)加密算法性能較低，但是安全性超強(qiáng)岸售，由于其加密特性几迄，非對(duì)稱(chēng)加密算法能加密的數(shù)據(jù)長(zhǎng)度也是有限的。
例如：RSA冰评、DSA、ECDSA木羹、 DH甲雅、ECDHE
3解孙、哈希算法
將任意長(zhǎng)度的信息轉(zhuǎn)換為較短的固定長(zhǎng)度的值，通常其長(zhǎng)度要比信息小得多抛人，且算法不可逆弛姜。
例如：MD5、SHA-1妖枚、SHA-2廷臼、SHA-256 等
4、數(shù)字簽名
簽名就是在信息的后面再加上一段內(nèi)容（信息經(jīng)過(guò)hash后的值）绝页，可以證明信息沒(méi)有被修改過(guò)荠商。hash值一般都會(huì)加密后（也就是簽名）再和信息一起發(fā)送，以保證這個(gè)hash值不被修改续誉。
詳解
一莱没、HTTP訪問(wèn)過(guò)程
抓包如下：
如上圖所示，HTTP請(qǐng)求過(guò)程中酷鸦，客戶端與服務(wù)器之間沒(méi)有任何身份確認(rèn)的過(guò)程饰躲，數(shù)據(jù)全部明文傳輸，“裸奔”在互聯(lián)網(wǎng)上臼隔，所以很容易遭到黑客的攻擊嘹裂，如下：
可以看到，客戶端發(fā)出的請(qǐng)求很容易被黑客截獲摔握，如果此時(shí)黑客冒充服務(wù)器寄狼，則其可返回任意信息給客戶端，而不被客戶端察覺(jué)盒发，所以我們經(jīng)常會(huì)聽(tīng)到一詞“劫持”例嘱，現(xiàn)象如下：
下面兩圖中，瀏覽器中填入的是相同的URL宁舰，左邊是正確響應(yīng)拼卵，而右邊則是被劫持后的響應(yīng)
所以 HTTP 傳輸面臨的風(fēng)險(xiǎn)有：
（1） 竊聽(tīng)風(fēng)險(xiǎn)：黑客可以獲知通信內(nèi)容。
（2） 篡改風(fēng)險(xiǎn)：黑客可以修改通信內(nèi)容蛮艰。
（3） 冒充風(fēng)險(xiǎn)：黑客可以冒充他人身份參與通信腋腮。
二、HTTP 向 HTTPS 演化的過(guò)程
第一步：為了防止上述現(xiàn)象的發(fā)生壤蚜，人們想到一個(gè)辦法：對(duì)傳輸?shù)男畔⒓用埽词购诳徒孬@即寡，也無(wú)法破解）
如上圖所示，此種方式屬于對(duì)稱(chēng)加密袜刷，雙方擁有相同的密鑰聪富，信息得到安全傳輸，但此種方式的缺點(diǎn)是：
（1）不同的客戶端著蟹、服務(wù)器數(shù)量龐大墩蔓，所以雙方都需要維護(hù)大量的密鑰梢莽，維護(hù)成本很高
（2）因每個(gè)客戶端、服務(wù)器的安全級(jí)別不同奸披，密鑰極易泄露
第二步：既然使用對(duì)稱(chēng)加密時(shí)昏名，密鑰維護(hù)這么繁瑣，那我們就用非對(duì)稱(chēng)加密試試
如上圖所示阵面，客戶端用公鑰對(duì)請(qǐng)求內(nèi)容加密轻局，服務(wù)器使用私鑰對(duì)內(nèi)容解密，反之亦然样刷，但上述過(guò)程也存在缺點(diǎn)：
（1）公鑰是公開(kāi)的（也就是黑客也會(huì)有公鑰）仑扑，所以第 ④ 步私鑰加密的信息，如果被黑客截獲颂斜，其可以使用公鑰進(jìn)行解密夫壁，獲取其中的內(nèi)容
第三步：非對(duì)稱(chēng)加密既然也有缺陷，那我們就將對(duì)稱(chēng)加密沃疮，非對(duì)稱(chēng)加密兩者結(jié)合起來(lái)盒让，取其精華、去其糟粕司蔬，發(fā)揮兩者的各自的優(yōu)勢(shì)
如上圖所示
（1）第 ③ 步時(shí)邑茄，客戶端說(shuō)：（咱們后續(xù)回話采用對(duì)稱(chēng)加密吧，這是對(duì)稱(chēng)加密的算法和對(duì)稱(chēng)密鑰）這段話用公鑰進(jìn)行加密俊啼，然后傳給服務(wù)器
（2）服務(wù)器收到信息后肺缕，用私鑰解密，提取出對(duì)稱(chēng)加密算法和對(duì)稱(chēng)密鑰后授帕，服務(wù)器說(shuō)：（好的）對(duì)稱(chēng)密鑰加密
（3）后續(xù)兩者之間信息的傳輸就可以使用對(duì)稱(chēng)加密的方式了
遇到的問(wèn)題：
（1）客戶端如何獲得公鑰
（2）如何確認(rèn)服務(wù)器是真實(shí)的而不是黑客
第四步：獲取公鑰與確認(rèn)服務(wù)器身份
1同木、獲取公鑰
（1）提供一個(gè)下載公鑰的地址，回話前讓客戶端去下載跛十。（缺點(diǎn)：下載地址有可能是假的彤路；客戶端每次在回話前都先去下載公鑰也很麻煩）
（2）回話開(kāi)始時(shí)，服務(wù)器把公鑰發(fā)給客戶端（缺點(diǎn)：黑客冒充服務(wù)器芥映，發(fā)送給客戶端假的公鑰）
2洲尊、那有木有一種方式既可以安全的獲取公鑰，又能防止黑客冒充呢奈偏？ 那就需要用到終極武器了：SSL 證書(shū)（申購(gòu)）
如上圖所示坞嘀，在第 ② 步時(shí)服務(wù)器發(fā)送了一個(gè)SSL證書(shū)給客戶端，SSL 證書(shū)中包含的具體內(nèi)容有：
（1）證書(shū)的發(fā)布機(jī)構(gòu)CA
（2）證書(shū)的有效期
（3）公鑰
（4）證書(shū)所有者
（5）簽名
………
3惊来、客戶端在接受到服務(wù)端發(fā)來(lái)的SSL證書(shū)時(shí)丽涩，會(huì)對(duì)證書(shū)的真?zhèn)芜M(jìn)行校驗(yàn)，以瀏覽器為例說(shuō)明如下：
（1）首先瀏覽器讀取證書(shū)中的證書(shū)所有者裁蚁、有效期等信息進(jìn)行一一校驗(yàn)
（2）瀏覽器開(kāi)始查找操作系統(tǒng)中已內(nèi)置的受信任的證書(shū)發(fā)布機(jī)構(gòu)CA矢渊，與服務(wù)器發(fā)來(lái)的證書(shū)中的頒發(fā)者CA比對(duì)检眯，用于校驗(yàn)證書(shū)是否為合法機(jī)構(gòu)頒發(fā)
（3）如果找不到，瀏覽器就會(huì)報(bào)錯(cuò)昆淡，說(shuō)明服務(wù)器發(fā)來(lái)的證書(shū)是不可信任的。
（4）如果找到刽严，那么瀏覽器就會(huì)從操作系統(tǒng)中取出 頒發(fā)者CA 的公鑰昂灵，然后對(duì)服務(wù)器發(fā)來(lái)的證書(shū)里面的簽名進(jìn)行解密
（5）瀏覽器使用相同的hash算法計(jì)算出服務(wù)器發(fā)來(lái)的證書(shū)的hash值，將這個(gè)計(jì)算的hash值與證書(shū)中簽名做對(duì)比
（6）對(duì)比結(jié)果一致舞萄，則證明服務(wù)器發(fā)來(lái)的證書(shū)合法眨补，沒(méi)有被冒充
（7）此時(shí)瀏覽器就可以讀取證書(shū)中的公鑰，用于后續(xù)加密了
4倒脓、所以通過(guò)發(fā)送SSL證書(shū)的形式撑螺，既解決了公鑰獲取問(wèn)題，又解決了黑客冒充問(wèn)題崎弃，一箭雙雕甘晤，HTTPS加密過(guò)程也就此形成
所以相比HTTP，HTTPS 傳輸更加安全
（1） 所有信息都是加密傳播饲做，黑客無(wú)法竊聽(tīng)线婚。
（2） 具有校驗(yàn)機(jī)制，一旦被篡改盆均，通信雙方會(huì)立刻發(fā)現(xiàn)塞弊。
（3） 配備身份證書(shū)，防止身份被冒充泪姨。
總結(jié)
綜上所述游沿，相比 HTTP 協(xié)議，HTTPS 協(xié)議增加了很多握手肮砾、加密解密等流程诀黍，雖然過(guò)程很復(fù)雜，但其可以保證數(shù)據(jù)傳輸?shù)陌踩匠āＫ栽谶@個(gè)互聯(lián)網(wǎng)膨脹的時(shí)代蔗草，其中隱藏著各種看不見(jiàn)的危機(jī)，為了保證數(shù)據(jù)的安全疆柔，維護(hù)網(wǎng)絡(luò)穩(wěn)定咒精，建議大家多多推廣HTTPS。
HTTPS 缺點(diǎn)：
（1）SSL 證書(shū)費(fèi)用很高旷档，以及其在服務(wù)器上的部署模叙、更新維護(hù)非常繁瑣
（2）HTTPS 降低用戶訪問(wèn)速度（多次握手）
（3）網(wǎng)站改用HTTPS 以后，由HTTP 跳轉(zhuǎn)到 HTTPS 的方式增加了用戶訪問(wèn)耗時(shí)（多數(shù)網(wǎng)站采用302跳轉(zhuǎn)）
（4）HTTPS 涉及到的安全算法會(huì)消耗 CPU 資源鞋屈，需要增加大量機(jī)器（https訪問(wèn)過(guò)程需要加解密）
二范咨、HTTPS實(shí)戰(zhàn)(獲取12306三字碼)
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;
/**
- @date 2018年2月24日
- @author junpu.guan
- @Description: Http工具封裝
**/
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));
}
}
