2、由於基於TCP/IP協議的通訊需要，HTTPS也還是必須暴露IP和Port出來，即這部分不在加密範疇之內。所以第三方還是可以通過截取網絡包數據等手段，知道用戶正在和哪個site通訊，當然，除了www.domain.com:port這部分數據之外，context後面的信息是加密的。
3、加密鏈接建立的核心基礎是SSL/TLS的握手過程，這個過程要比TCP協議建立鏈接的3次握手過程複雜一些。參考了wikipedia中描述的過程http://en.wikipedia.org/wiki/Transport_Layer_Security，自己大概整理了一下這個握手過程，大概是下面這個樣子的：
4、從上面的這個過程可以總結一下這個安全鏈接建立的過程：
- client和server通訊爲了保證安全性，所以通訊的消息得加密，即網絡上密文傳輸。爲了方便對方獲得真實的消息，這個加密得使用對稱加密算法。於是，這個加密的安全性就取決於密鑰本身的強度以及所選用的對稱加密算法了。
- 可是到底用什麼密鑰和對稱加密算法呢？client和server互不認識，怎麼會有默契上來就知道這兩個東東都用啥？於是這事兒得client和server談判！
- client給server發送了個ClientHello，裏面包括：client能支持的TLS的最高版本、一個隨機數A、client所能支持的加密算法集合、client所能支持的壓縮算法集合。
- server收到個ClientHello之後，拿出自己所能支持的TLS的最高版本跟client發過來的最高版本比較一下，這兩個版本取個Max，這裏標記爲：max_TLS_version。server自己再生成個隨機數B，從client傳過來的加密算法集合中挑一個具體的加密算法M（注意，這裏的M其實也是一個集合，包括：非對稱加密算法用於加密上圖的pre-master secret，比如RSA算法、對稱加密算法用於數據傳輸時雙方使用的加密自己的內容解密對方內容的依據、MAC算法用於校驗信息是否被篡改、僞隨機算法用於生成最終通訊時對稱加密算法所需要的密鑰master secret），從壓縮算法集合中挑一個具體的壓縮算法N。然後發送一個ServerHello作爲迴應給client，這個ServerHello就包括上面提到的max_TLS_version/B/M/N。
- 注意，這時client和server雙方之間的信息基本比較對稱了。因爲雙方已經協商好整個握手過程中所有可能需要涉及到的算法。
- server發送自己經過第三方認證的證書給client，告訴他：哥是有證經營的，你可以拿我的證去隨便調查。
- client拿着server發過來的證書跑去權威的有關部門驗證去了。。。（這兩步涉及到的CA證書認證內容又很大，這裏不展開描述，先將主要精力放在TLS握手上）
- 假設上面的證書驗證通過了，這就意味着client相信server發過來的證書了，也就意味着client同意用server發過來的public key開始通訊了。注意，非對稱加密的過程在這裏開始了。client生成了一個pre-master secret（通常也是一個隨機數）P，使用server提供的public key加密P之後生成P'， 將P'發給了server。
- server收到P'後，用自己的private key解密還原出了P。注意這個P和之前A的最大不同是加密傳輸過來的哦。而且理論上在server沒有泄露自己private key的情況下， 只有server能夠從P'還原出P。So，此時，client和server雙方已經具備了生成雙方後面通訊時對稱加密需要使用的master secret的條件：雙方都有的一個確定的僞隨機函數、3個彼此都知道的隨機數A、B和P。
- 於是，雙方在自己一方，通過共同的僞隨機數和共同的素材，生成出來了master secret。到這裏，雙方談判的過程基本上可以結束了。因爲談判的初衷已經完全符合了。回想一下，整個過程不就是爲了在公網上這個非安全的環境中讓彼此都清楚使用啥對稱加密算法以及使用什麼密鑰嗎？等等，這個握手過程爲了保證可用性，還拿出來先測試一下，是否真的行得通才行啊。於是還有下面的兩步。
- client用雙方同意的MAC（message authentication code）算法，比如MD5，加密一段明文Q（這個明文是啥應該都沒關係，因爲都會發給server的）生成了MAC。然後用雙方同意的對稱加密算法（比如AES）加密了Q和MAC之後，生成了一段Finished Message發給了server。（這裏，根據TLS record protocol，這個Finished Message其實是個具體的TLS record，他攜帶的Content type爲20，這相當於告訴server：I am ready to begin the normal communication.）
- server收到這條TLS record之後，就會嘗試先解密密文（Decryption），再用約定的MAC算法驗證內容是否被篡改（Verification）。這時，如果這兩個任何一項工作失敗了，就前功盡棄了。。。這裏假設都成功了，於是server做了上一步client同樣的事情：生成一份Content type爲20的Finished Message，發給client。至此，整個握手過程正式結束。。。下面的通訊就是雙方直接使用對稱加密算法直接加解密message的過程啦，當然每次交互的過程中，還會包括上面描述的MAC驗證的過程。