china麻豆天美,火影奖励网站V.2.8.7破解版,国产原创精品视频,236宅宅最新俚片,一起草视频在线,freeHD18 麻豆养身,边喂奶边中出的人妻,辽宁老熟女高潮狂叫视频,动漫美女内衣,老司机午夜剧免费,国产传媒无码,毛茸茸BwBwBw,探索新潮风尚,hd国产高清在线视频,《91看片链接》:高清在线,初中男生袜子舒适玩法

在你每天登錄 B站、騰訊視頻的時候，有沒有想過一個問題：

?? 為什么你關閉瀏覽器之后，再打開居然不用重新登錄？

?? 又為什么，有些網站一旦 Cookie 被偷，就能“免密登錄”？

更可怕的是——
如果有人拿到了你的 Cookie，他甚至可以直接冒充你登錄賬號。

這背后，其實涉及三個核心知識：

• Cookie（身份憑證）
• Session（服務端身份管理）
• HTTPS（真正的安全保障）

今天直接從“中間人視角”來了解一下整個流程。

Cookie

現在我們通過生活中的例子進行理解cookie，相信大家在網頁中登錄B站，或則騰訊視頻等等網頁的時候，一般都需要我們進行賬號登錄，我們完成賬號登錄之后就可以對其進行訪問了，但是當我們訪問完成之后，將其關閉，在一段時間內如果我們重新登錄，我們就不需要再進行賬號登錄，可以直接使用，這是怎么做到的呢，這其實就是HTTP會對登錄用戶的會話具有保持的功能，具體情況就是如下：

1. 瀏覽器發送請求（帶用戶名+密碼）
2. B站服務器認證

3. 服務器返回：

   Set-Cookie: username=bulouo&password=12345678

4. 瀏覽器保存 Cookie
5. 后續請求自動攜帶 Cookie（用戶名+密碼）

我們也可以通過我們上一篇博客中的代碼進行驗證，只在響應報文中的報頭中增加Set-Cookie: username=bulouo&password=12345678

class HttpServer
{
public:
    HttpServer(uint16_t port, std::string ip)
        : port_(port), ip_(ip)
    {
    }
    void Init()
    {
        listenfd_.Init();
        listenfd_.Bind(port_, ip_);
        listenfd_.Listen();
    }
    void start()
    {
        while (1)
        {
            uint16_t client_port;
            std::string client_ip;
            int sockfd = listenfd_.Accept(&client_port, &client_ip);
            if (sockfd < 0)
            {
                continue;
            }
            ThreadData *td = new ThreadData(sockfd, this);
            pthread_t tid;
            pthread_create(&tid, nullptr, ThreadRun, td);
        }
    }
    static void *ThreadRun(void *arg)
    {
        pthread_detach(pthread_self());
        ThreadData *td = (ThreadData *)arg;
        td->ts_->HttpHandler(td->sockfd_);
        delete td;
        return nullptr;
    }
    std::string ReadHtmlContent(std::string &htmlpath)
    {
        std::string content;
        std::ifstream in(htmlpath.c_str());
        if (!in.is_open())
        {
            return "404";
        }
        std::string line;
        while (std::getline(in, line))
        {
            content += line;
        }
        in.close();
        return content;
    }
    void HttpHandler(int sockfd)
    {
        char buffer[1024];
        ssize_t s = read(sockfd, buffer, sizeof buffer - 1);
        std::string request;
        if (s > 0)
        {
            buffer[s] = 0;
            std::cout << buffer << std::endl;
            request = buffer;
            std::vector<std::string> req_header;
            while (!request.empty())
            {
                ssize_t pos = request.find("\r\n", 0);
                if (pos == std::string::npos)
                {
                    break;
                }
                std::string line = request.substr(0, pos);
                if (line.empty())
                {
                    break;
                }
                req_header.push_back(line);
                request.erase(0, pos + 2);
            }
            std::stringstream ss(req_header[0]);
            std::string method;
            std::string url;
            std::string http_version;
            ss >> method >> url >> http_version;
            //std::cout << "method:" << method << "url:" << url << "httpversion" << http_version << std::endl;
            std::string path = url;
            if (path == "/" || path == "/index.html")
            {
                path = wwwroot + "/index.html";
            }
            else
            {
                path = wwwroot + url;
            }
            std::string text = ReadHtmlContent(path);
            std::string response;
            if (text == "404")
            {
                std::string body = "<h1>404 Not Found</h1>";
                response = "HTTP/1.0 404 Not Found\r\n";
                response += "Content-Length: " + std::to_string(body.size()) + "\r\n";
                response += "Content-Type: text/html\r\n";
                response += "\r\n";
                response += body;
            }
            else
            {
                response = "HTTP/1.0 200 OK\r\n";
                response += "Content-Length: " + std::to_string(text.size()) + "\r\n";
                response += "Content-Type: text/html\r\n";
                response += "Set-Cookie: name=buluo&&password=12345678\r\n";
                response += "\r\n";
                response += text;
            }
            write(sockfd, response.c_str(), response.size());
        }
        close(sockfd);
    }
    ~HttpServer()
    {
    }
private:
    Socket listenfd_;
    uint16_t port_;
    std::string ip_;
};

從結果來看，我們的瀏覽器就將我們的登錄信息保存到了cookie文件中，并且當我們再次進行訪問服務器時，會在請求報頭中增加一個Cookie字段，通過這樣的方式，我們就可以在一次登錄之后的一段時間內，可以直接訪問服務器，不需要再進行身份驗證。

這就是Cookie的作用?，F在我們通過這個內容結合一個例子引出我們今天的主要內容。

在一個月黑風高的夜晚，你閑來無事，一不小心打開一些視頻網站進行學習，在你學習的過程中，這些網站的程序員就很有可能會在你的電腦上種植一些木馬病毒，這些人就有可能在你的電腦上啟動一些軟件，這些軟件就有可能會全文式的掃描你的瀏覽器中的cookie文件，一旦就你的cookie文件拿走之后，他一旦通過這個cookie文件和你訪問同一個網頁，就有可能直接就免密登錄，甚至通過cookie文件，我們一些個人信息就被泄漏了，那么這樣的情況該如何解決呢？

正確流程是這樣子的：

1. 瀏覽器發送：

   username + password

2. 服務器認證成功后：
   • 生成 session_id
   • 在服務器保存 session（session文件/內存/數據庫），將用戶信息內容保存在其中

3. 返回給用戶：

   Set-Cookie: session_id

4. 瀏覽器保存 Cookie

5. 后續請求：

   Cookie: session_id

6. 服務器通過 session_id 找到用戶，一旦如果錯誤，就會要求用戶重新進行登錄驗證

這樣就保護了我們的個人信息不再泄漏，即使黑客再次拿到我們的cookie文件，cookie中只會有一個session_id ，這樣就確保了我們個人信息的安全，至于黑客拿到我們的cookie文件想要獲取我們的密碼，就讓這些黑客去和服務器的程序員進行battle吧，這樣就不需要我們普通人進行擔心了。

雖然通過這樣的方式保證了我們的個人信息不會輕易泄漏，但是我們的http是明文進行傳輸的，我們通過POST方法傳輸我們的賬號信息時，對于小白來講不懂，但是對于稍微懂一點的程序員都知道，賬號信息其實就在請求報文中的正文部分，所以這樣明文傳送的方式，是很容易讓其它人抓包然后獲取到的，所以http是不安全的，所以為了安全起見，就會有另一個協議的誕生，就是HTTPS

HTTPS是什么

HTTPS也是一個應用層協議，就是在HTTP協議的基礎上引入一個加密層。

這張圖本質上展示的是 HTTPS 的分層結構和數據傳輸過程。HTTPS 并不是替代 HTTP，而是在應用層的 HTTP 與傳輸層的 TCP 之間加入了一層 SSL/TLS 加密層。具體來說，客戶端在發送請求時，首先由 HTTP 生成明文請求數據，然后交由 SSL/TLS 層進行加密處理，加密后的數據再通過 TCP 在網絡中傳輸；服務器接收到數據后，先由 TCP 層接收密文，再交給 SSL/TLS 層進行解密，還原出原始的 HTTP 請求，隨后服務器處理請求并生成 HTTP 響應，同樣經過 SSL/TLS 加密后再通過 TCP 發送給客戶端，客戶端再進行解密得到最終內容。也就是說，HTTP 負責定義“傳輸什么內容”，而 SSL/TLS 負責保證“如何安全傳輸”，因此在網絡中實際傳輸的始終是加密后的密文，從而有效防止數據被竊取或篡改。這也意味著，即使在使用 Cookie 和 Session 機制的情況下，只有在 HTTPS 環境下，這些敏感信息才能在傳輸過程中得到真正的安全保障。

什么是加密和解密

加密就是把要傳輸的明文內容進行一系列的變化，生成密文。

解密就是把密文再進行一系列的變化，還原為明文。

在這個加密和解密的過程中，往往需要一個或者多個中間的數據進行輔助這個過程，這樣的數據稱為密鑰

這個是什么意思呢？舉一個簡單的例子就明白了。

假設我想向另一個人發送數字 7（明文），但我們事先約定了一種規則：所有發送的數據都要與數字 5 進行異或運算（XOR）。那么在發送之前，我會先對數據進行處理：

7 ^ 5 = 2

于是我發送的實際上是數字 2（密文）。接收方在拿到 2 之后，同樣按照約定規則再進行一次異或運算：

2 ^ 5 = 7

這樣就成功還原出了原始數據 7。

在這個過程中：

• 7 是明文
• 2 是密文
• 5 就是用于加密和解密的密鑰

為什么要加密

著名的就是臭名昭著的就是“運營商劫持”

說起這個名字大家可能沒有感覺，但是一說到具體的事情，大家就了解的一清二楚了，在我們小時候，一到寒暑假的時候，大家都迫不及待的想可以玩到電腦，于是拿著自己的零花錢就到附近的網吧去開機上網，打開電腦的第一件事就是下載你想要完的游戲，于是你打開了瀏覽器，看到了一個你想玩游戲的下載鏈接，于是你點擊進行下載，但是下載完成之后，你卻發現下載了一個其它的不知道是干什么的玩意，與你想要下載的游戲八竿子打不到一起去，這就是運營商劫持。

由于我們通過網絡傳輸的任何數據包都會經過運營商的網絡服務器，那么運營商的網絡設備就可以解析出你傳輸的數據內容，并進行篡改，當我們點擊下載按鈕之后，其實就是給服務器發送一個HTTP請求，獲取到的HTTP響應其實就包含了你想要下載游戲的下載鏈接，但是由于你的傳送方式是通過HTTP這種明文方式傳送，這就很容易被運營商劫持，就將你想要下載的內容篡改為其它軟件的下載地址，這樣就導致幼小的我們傻傻的下載成其它的軟件。

就是因為http的內容是明文進行傳送的，明文數據在經過路由器，通信服務運營商等多個物理節點，如果信息在傳輸的過程中被劫持了，傳輸的內容就會暴露。劫持者就可以篡改傳輸的內容，并且客戶端和服務器還不知道，這個就是中間人攻擊，所以我們要對我們傳輸的信息進行加密。

至于運營商為什么這么做呢？

總而言之就是在互聯網中，明文進行傳輸是非常危險的事情，HTTPS就是在HTTP的基礎上進行了加密，進一步保護用戶的數據安全。

常見的加密方式

對稱加密

• 采用單鑰密碼系統的加密方式，同一個密鑰可以同時用作信息的加密和解密，這種加密方式就是對稱加密，也稱為單密鑰加密，特征：就是加密和解密所使用的密鑰是相同的。
• 常見的對稱加密算法：DES、3DES、AES、TDEA等
• 特點：計算量小，加密速度快，加密效率高，算法公開。

對稱加密就是通過同一個密鑰，把明文加密成密文，再將密文解密為明文，就如同我們上面7^5 = 2 ， 2^5 = 7，這就是一個簡單的對稱加密。

非對稱加密

• 需要兩個密鑰進行加密和解密，這兩個密鑰叫做公開密鑰和私有密鑰
• 常見的非對稱加密算法：RSA，DSA，ECDSA
• 特點：就是算法強度復雜，安全性依賴于算法于密鑰，但是由于算法的復雜，所以加密解密的速度相對之下沒有對稱加密快

非對稱加密要用到的兩個密鑰，一個叫做“公鑰”，一個叫做"密鑰"，公鑰和私鑰是配對的。

通過公鑰對明文進行加密，變成密文。

通過私鑰對密文進行解密，變成明文。

也可以反著來

通過私鑰對明文進行加密，變成密文。

通過公鑰對密文進行解密，變成明文。

舉一個生活中的例子就是假如有一天你的朋友要給你一個很重要的東西，但是你不在宿舍，這個時候，你就對你的朋友說，你將這個東西放到我桌子上的盒子里，然后拿旁邊的鎖將它鎖起來，我回頭拿我的鑰匙將他再打開。

在這個例子中這個鎖就是公鑰，鑰匙就是密鑰，公鑰給誰都行，無所謂，但是密鑰只能是我們自己持有才行，這樣只有我們才能對其進行解密。

數據摘要（數據指紋）

數據摘要（數據指紋），其基本原理是利用單向散列函數(Hash函數)對信息進行運算，生成一串固定長度的數字摘要。數字指紋并不是一種加密機制，但是可以用來判斷數據有沒有被篡改。

數據摘要常見的算法：有MD5，SHA1，SHA256等，但是也會有數據碰撞的問題(就是兩個不同的信息，算出的摘要確實相同的，有這種可能，但是概率是比較低的)

數據摘要的特征：和加密算法的區別是：摘要的嚴格意義其實不是加密，因為并沒有解密，只不過從摘要很難發推原信息，通常用來進行數據對比。

例如：

"hello" → MD5 → 5d41402abc4b2a76b9719d911017c592

即使只改一個字符：

"hello!" → MD5 → 不同的摘要

所以數據摘要就是通過Hash算法將任意長度數據映射為固定長度摘要的方式。

數字簽名

就是將數據摘要通過非對稱加密，就得到了數字簽名。

HTTPS的工作過程的探究

既然要保護數據的安全，那就需要進行"加密"。網絡傳輸中不再直接傳輸明文了，而是加密之后的密文。加密的方式很多，整體分為兩大類:對稱加密和非對稱加密。

方案一：只是用對稱加密

如果通信雙發都各自持有同一個密鑰X，并且沒有人知道，那么彼此雙方的通信安全就是可以被保證的(除非密鑰被破解)。

引入對稱加密之后，即使數據被截獲，由于黑客是不知道密鑰是什么，所以也就無法進行解密，也就不知道數據的真實內容是什么。但是，事情是沒有這么簡單的，服務器同一時刻其實是給很多客戶端提供服務的，這么多的客戶端，每個人用的密鑰都必須不同，如果相同，萬一那一天一個密鑰被黑客拿到了，這不是整鍋都被端了，所以服務器需要維護每一個客戶端和每個密鑰之間的關聯關系，這是相當麻煩的事情。

但是其實客戶端和服務器約定好一個密鑰這樣的事情是十分不靠譜的，因為服務器是公司在進行維護，相對是安全的，而客戶端的使用者一般都是小白，其實黑客只要入侵了你的電腦，想要獲取到你的密鑰內容是很容易的，這樣對數據的保護成本就大大增加了。

并且假如有一天服務器需要對密鑰進行更新的話，已經使用的客戶端時成百上千的用戶也得跟著改，這樣牽一發而動全身的事情，是不利用產品的使用的，所以這樣的方式是不可取的。

這時候就有人想到了一種解決辦法就是，既然客戶端保管不利，直接讓客戶端在使用之前先申請密鑰，獲得密鑰之后再進行數據的傳輸，這樣客戶端就不需要一直持有密鑰了。

但是這樣就有點左腦攻擊右腦的現象了，既然我們在獲取密鑰的時候，不也是要進行數據傳輸的么，這個時候是明文傳送還是密文傳送，明文傳送，黑客直接就拿到了，密文傳送，你又沒有密鑰如何進行密文傳送，即使你這邊加密形成密文傳輸了，對端如何解密，這不就是脫褲子放屁，多此一舉么，所以通過對稱加密的方式是不可取的。

方案二：只使用非對稱加密

鑒于非對稱加密的機制，如果服務器先把公鑰以明文的方式交給客戶端，之后客戶端向服務器傳輸數據前先用這個公鑰加密之后進行傳輸，這樣似乎從客戶端到服務器的信道就是安全的，因為只有服務器的密鑰才能解開公鑰加密的數據，但是服務器到客戶端如何才能保障安全？

如果服務器用它的私鑰加密的數據傳給客戶端，那么客戶端可以用公鑰進行解密，這個公鑰也是明文進行傳輸的，一旦這個公鑰被黑客拿到了，那他同樣也可以使用公鑰來對服務器傳送的數據進行解密。

方案三：雙方都使用非對稱加密

• 服務端擁有公鑰S和對應的私鑰S‘?？蛻舳藫碛泄€C和對應的密鑰C‘
• 客戶端和服務器交換公鑰
• 客戶端給服務器發送消息，先用S對數據進行加密，在發送，然后服務器進行解密，因為只有服務器有密鑰S‘
• 服務器給客戶端發送消息，先用C對數據進行加密，再發送，然后客戶端進行解密，因為只有客戶端有密鑰C‘

方案四：非對稱加密+對稱加密

• 服務端具有非對稱加密的公鑰S和私鑰S‘
• 客戶端發送https請求，獲得了服務端的公鑰S
• 客戶端在本地生成對稱加密的密鑰C，通過公鑰S加密，發送給服務器
• 由于黑客沒有私鑰，即使截獲了數據，也無法還原明文數據，也就無法獲取到對稱加密的密鑰
• 服務器通過私鑰S‘解密，還原了客戶端發來的對稱加密的密鑰C，并且使用這個對稱加密的密鑰對響應的數據進行加密傳輸。
• 后續只需要客戶端與服務器的通信使用對稱加密即可，由于該密鑰只要客戶端和服務器兩個主機知道，其他人并不知道密鑰，所以即使截獲了數據，也是沒有任何用。

雖然看上去方案二，三，四可行，但是都存在一個致命的問題就是，如果剛開始的時候，黑客就進行攻擊了呢？

中間人攻擊

這種攻擊方式叫做："MIMT攻擊"。

在方案二，三，四中，客戶端獲取到公鑰之后，對客戶端形成的對稱密鑰用服務端的公鑰進行加密，中間人即使截取到了數據，此時也是無法解出客戶端形成的密鑰，因為只有服務端有私鑰。但是一旦黑客在剛開始的時候就進行了攻擊，這一切的努力就化為泡影了。

1. 服務器現在具有非對稱加密算法的公鑰S和私鑰S‘
2. 黑客也同樣準備好一個非對稱加密算法的公鑰M和私鑰M‘
3. 客戶端向服務器發送請求，服務器明文傳送公鑰S給客戶端
4. 這個時候黑客劫持了數據內容，提取出了其中的公鑰S并且保存下來，然后將報文中的公鑰S替換為自己的公鑰M，然后將偽造后的報文給客戶端。
5. 客戶端在拿到報文之后，提取公鑰M(客戶端完全不知道公鑰已經被替換了)，客戶端自己形成對稱密鑰X，用公鑰M加密X，形成報文發送給服務器。
6. 這個時候黑客再次截取了數據內容，直接用自己的私鑰M‘進行解密，獲得了客戶端傳送的對稱加密的密鑰X，然后他再用之前截取到服務端的公鑰S加密后，將報文傳送給服務器。
7. 服務器拿到報文之后，用自己的私鑰S‘進行解密，得到了密鑰X。
8. 客戶端和服務器就開始采用X進行對稱加密，開始通信，但是黑客也早已知道了對稱加密的密鑰X，所以客戶端和服務器傳送的一切數據，對于黑客來講和明文數據沒什么區別。

所以問題的本質出在哪里呢？其實就是客戶端無法確認收到含有公鑰的數據報文，是不是就是服務器發送過來的！

引入證書

CA認證

服務端在使用HTTPS之前，需要向CA機構申領一份數字證書，數字證書里含有證書申請者信息，公鑰信息等。服務器把證書傳送給瀏覽器，瀏覽器從證書中獲取公鑰即可，證書就像身份證一樣，證明服務端公鑰的正確性。

首先就是服務端將自己的域名，申請者(公司法人)，以及自己的公鑰等等信息提交給CA機構，然后CA機構會使用一些公開的hash算法對這些信息進行運算，形成一串固定長度的數據摘要，然后CA機構會使用自己的私鑰(注：CA機構會有自己的公鑰和私鑰)，將這個數據摘要信息形成密文數據，這個密文數據就是數據簽名，然后CA機構會將服務端提交上來的數據與數據簽名合在一起，這樣就形成了CA證書。

當服務端申請CA證書的時候，CA機構會對服務端進行審核，并且為其形成專門的數字簽名，過程如下：

• CA機構也擁有屬于自己的非對稱加密的公鑰A和私鑰A'
• CA機構對服務端申請的證書的明文數據(就是上圖中CA證書中的明文信息)進行hash算法，形成數據摘要
• 然后對數據摘要用CA機構的私鑰A‘對其進行加密，得到數字簽名S

服務端申請的證書明文和數字簽名就共同構成了數字證書，這樣一份數字證書就可以頒發給服務端了。

方案五：非對稱加密+對稱加密+證書認證

在客戶端和服務器剛建立連接的時候，服務器給客戶端返回一個證書，證書包含之前服務端的公鑰，以及一些身份信息，以及數據簽名，客戶端在拿到CA證書之后，驗證CA證書的合法性，驗證成功之后，將使用證書中的公鑰對自己接下來要使用的對稱加密傳輸的密鑰進行密文傳輸，然后服務器拿到這個密文之后，使用自己的私鑰進行解密，得到對稱加密的密鑰信息，之后客戶端和服務器就可以進行對稱加密方式的信息傳輸。

那么客戶端是如何對這個CA證書進行驗證呢？

將CA證書中的數據(服務器交給CA機構的信息)和數據簽名進行分離，然后將數據通過和CA機構使用一樣的hash算法，形成一個數據摘要，而由于數據簽名是CA機構通過密鑰形成的，所以我們只需要使用CA機構的公鑰(CA機構的公鑰在我們的電腦中會內置)就可以將數字簽名反轉回數據摘要，這樣對比兩個數據摘要是否相同，這樣就可以判斷這個CA證書是否屬于合法。如果相同，就證明這個CA證書是可信的，這樣就保證了CA證書中的公鑰是合法的，不是中間人篡改后的。

現在如果中間人拿到這個CA認證之后，想要替換CA證書中的公鑰已經是不可能了，一旦他將公鑰進行替換，客戶端在進行CA驗證的時候，就會發現數據形成的數據摘要，和數據簽名形成的數據摘要不一致，這樣就這知道了有人修改了我們的公鑰。

那有人就會說如果中間人將這個數據簽名也修改了呢？

• 由于它沒有CA機構的私鑰，所以無法hash之后用私鑰加密形成簽名，也就沒有辦法對篡改后的證書形成匹配的簽名
• 如果強行篡改，客戶端收到該證書之后會發現明文和簽字解密后的值是不一樣的，這樣就證明證書被篡改，證書不可信。

那要是將中間人整急眼了，自己申請一個真的證書，然后進行掉包怎么辦？

• 弄一個真的證書，是要提交申請人的信息，這樣相當于自投羅網了，得不償失。
• 另外就算中間人將整個證書替換為自己申請的證書，證書中的明文內容又域名信息的，我們總不可能要訪問百度的首頁，跳轉到谷歌的首頁，這樣客戶端一下子就看出來了
• 總之，就是中間人沒有CA私鑰，對證書是無法盡心修改的。

我們可以看看我們瀏覽器中一些CA機構公開的公鑰。

所以CA機構的公鑰我們是可以獲取到的，不用擔心。

總之就是：

HTTPS = 非對稱加密（交換密鑰） + 對稱加密（傳輸數據） + CA證書（身份認證）