• <ul id="cgeq2"></ul>
  • 歡迎您光臨深圳塔燈網絡科技有限公司!
    電話圖標 余先生:13699882642

    網站百科

    為您解碼網站建設的點點滴滴

    Https及獲取12306信息

    發表日期:2018-03 文章編輯:小燈 瀏覽次數:2756

    轉自:【HTTP】HTTPS 原理詳解

    一、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.jpg

    如上圖所示 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.jpg

    抓包如下:

    http Sniffer.png

    如上圖所示,HTTP請求過程中,客戶端與服務器之間沒有任何身份確認的過程,數據全部明文傳輸,“裸奔”在互聯網上,所以很容易遭到黑客的攻擊,如下:

    http Naked.jpg

    可以看到,客戶端發出的請求很容易被黑客截獲,如果此時黑客冒充服務器,則其可返回任意信息給客戶端,而不被客戶端察覺,所以我們經常會聽到一詞“劫持”,現象如下:

    下面兩圖中,瀏覽器中填入的是相同的URL,左邊是正確響應,而右邊則是被劫持后的響應

    http hacker.jpg

    所以 HTTP 傳輸面臨的風險有:

    (1) 竊聽風險:黑客可以獲知通信內容。

    (2) 篡改風險:黑客可以修改通信內容。

    (3) 冒充風險:黑客可以冒充他人身份參與通信。

    二、HTTP 向 HTTPS 演化的過程

    第一步:為了防止上述現象的發生,人們想到一個辦法:對傳輸的信息加密(即使黑客截獲,也無法破解)

    對稱加密.jpg

    如上圖所示,此種方式屬于對稱加密,雙方擁有相同的密鑰,信息得到安全傳輸,但此種方式的缺點是:

    (1)不同的客戶端、服務器數量龐大,所以雙方都需要維護大量的密鑰,維護成本很高

    (2)因每個客戶端、服務器的安全級別不同,密鑰極易泄露

    第二步:既然使用對稱加密時,密鑰維護這么繁瑣,那我們就用非對稱加密試試

    非對稱加密.jpg

    如上圖所示,客戶端用公鑰對請求內容加密,服務器使用私鑰對內容解密,反之亦然,但上述過程也存在缺點:

    (1)公鑰是公開的(也就是黑客也會有公鑰),所以第 ④ 步私鑰加密的信息,如果被黑客截獲,其可以使用公鑰進行解密,獲取其中的內容

    第三步:非對稱加密既然也有缺陷,那我們就將對稱加密,非對稱加密兩者結合起來,取其精華、去其糟粕,發揮兩者的各自的優勢

    非對稱加密01.jpg

    如上圖所示

    (1)第 ③ 步時,客戶端說:(咱們后續回話采用對稱加密吧,這是對稱加密的算法和對稱密鑰)這段話用公鑰進行加密,然后傳給服務器

    (2)服務器收到信息后,用私鑰解密,提取出對稱加密算法和對稱密鑰后,服務器說:(好的)對稱密鑰加密

    (3)后續兩者之間信息的傳輸就可以使用對稱加密的方式了

    遇到的問題:

    (1)客戶端如何獲得公鑰

    (2)如何確認服務器是真實的而不是黑客

    第四步:獲取公鑰與確認服務器身份

    非對稱加密02.png

    1、獲取公鑰

    (1)提供一個下載公鑰的地址,回話前讓客戶端去下載。(缺點:下載地址有可能是假的;客戶端每次在回話前都先去下載公鑰也很麻煩)

    (2)回話開始時,服務器把公鑰發給客戶端(缺點:黑客冒充服務器,發送給客戶端假的公鑰)

    2、那有木有一種方式既可以安全的獲取公鑰,又能防止黑客冒充呢? 那就需要用到終極武器了:SSL 證書(申購)

    非對稱加密03.jpg

    如上圖所示,在第 ② 步時服務器發送了一個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訪問過程需要加解密)

    二、HTTPS實戰(獲取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)); } 

    }

    image.png
    本頁內容由塔燈網絡科技有限公司通過網絡收集編輯所得,所有資料僅供用戶學習參考,本站不擁有所有權,如您認為本網頁中由涉嫌抄襲的內容,請及時與我們聯系,并提供相關證據,工作人員會在5工作日內聯系您,一經查實,本站立刻刪除侵權內容。本文鏈接:http://www.juherenli.com/20466.html
    相關開發語言
     八年  行業經驗

    多一份參考,總有益處

    聯系深圳網站公司塔燈網絡,免費獲得網站建設方案及報價

    咨詢相關問題或預約面談,可以通過以下方式與我們聯系

    業務熱線:余經理:13699882642

    Copyright ? 2013-2018 Tadeng NetWork Technology Co., LTD. All Rights Reserved.    

    • QQ咨詢
    • 在線咨詢
    • 官方微信
    • 聯系電話
      座機0755-29185426
      手機13699882642
    • 預約上門
    • 返回頂部
    国产精品永久免费| 亚洲国产精品特色大片观看完整版 | 久久99久久99精品免观看不卡| 亚洲精品资源在线| 国产精品亚洲一区二区三区| 亚洲欧洲精品无码AV| 精品国产一区二区三区四区| 精品一区二区三区电影| 久久国产精品自由自在| 国产精品久久久久一区二区三区| 国产一区麻豆剧传媒果冻精品 | 亚洲日韩精品无码专区加勒比| 国产VA免费精品高清在线| 久久99精品国产麻豆| 国产主播精品福利19禁vip| 久99久热只有精品国产男同| 国产精品嫩草影院一二三区| 精品国产自在钱自| 无码人妻精品一区二区三区东京热 | 久久老子午夜精品无码怎么打| 香港三级精品三级在线专区| 久久精品国产99国产| 99热在线日韩精品免费| 国产高清在线精品一区二区三区 | 91精品啪在线观看国产电影| 亚洲精品A在线观看| 久99久热只有精品国产女同| 久久国产精品一区二区| 国产热re99久久6国产精品| 久久久久女人精品毛片| 久久精品国产96精品亚洲| 国内精品九九久久久精品| 日韩久久精品一区二区三区| 乱码精品一区二区三区| 精品国产成人国产在线观看 | 国产精品成人亚洲| 欧洲精品码一区二区三区| 久久精品无码中文字幕| 久久棈精品久久久久久噜噜| 亚洲国产精品乱码一区二区| 久久er热视频在这里精品|