HTTP請求報頭： Authorization
HTTP響應報頭： WWW-Authenticate
HTTP認證是基于質詢/回應(challenge/response)的認證模式。
當一個用戶端向HTTP伺服器進行資料請求時，如果用戶端未被認證，則HTTP伺服器将通過基本認證過程對用戶端的使用者名及密碼進行驗證，以決定使用者是否合法。
用戶端在接收到HTTP伺服器的身份認證要求後，會提示使用者輸入使用者名及密碼，然後将使用者名及密碼以BASE64加密，加密後的密文将附加于請求資訊中， 如當使用者名為anjuta，密碼為：123456時，用戶端将使用者名和密碼用“：”合并，并将合并後的字元串用BASE64加密為密文，并于每次請求資料時，将密文附加于請求頭（Request Header）中。HTTP伺服器在每次收到請求包後，根據協定取得用戶端附加的使用者資訊（BASE64加密的使用者名和密碼），解開請求包，對使用者名及密碼進行驗證，如果使用者名及密碼正确，則根據用戶端請求，傳回用戶端所需要的資料;否則，傳回錯誤代碼或重新要求用戶端提供使用者名及密碼。
基本認證步驟：
1、用戶端通路一個受http基本認證保護的資源。
2、伺服器傳回401狀态，要求用戶端提供使用者名和密碼進行認證。（驗證失敗的時候，響應頭會加上WWW-Authenticate: Basic realm="請求域"。）
3、用戶端将輸入的使用者名密碼用Base64進行編碼後，采用非加密的明文方式傳送給伺服器。
4、伺服器将Authorization頭中的使用者名密碼解碼并取出，進行驗證，如果認證成功，則傳回相應的資源。如果認證失敗，則仍傳回401狀态，要求重新進行認證。
特記事項：
1、Http是無狀态的，同一個用戶端對同一個realm内資源的每一個通路會被要求進行認證。
2、用戶端通常會緩存使用者名和密碼，并和authentication realm一起儲存，是以，一般不需要你重新輸入使用者名和密碼。
3、以非加密的明文方式傳輸，雖然轉換成了不易被人直接識别的字元串，但是無法防止使用者名密碼被惡意盜用。雖然用肉眼看不出來，但用程式很容易解密。
基本認證的一個優點是基本上所有流行的網頁浏覽器都支援基本認證。基本認證很少在可公開通路的網際網路網站上使用，有時候會在小的私有系統中使用（如路由器
網頁管理接口）。後來的機制HTTP摘要認證是為替代基本認證而開發的，允許密鑰以相對安全的方式在不安全的通道上傳輸。
雖然基本認證非常容易實作，但該方案建立在以下的假設的基礎上，即：用戶端和伺服器主機之間的連接配接是安全可信的。特别是，如果沒有使用SSL/TLS這樣的傳輸
層安全的協定，那麼以明文傳輸的密鑰和密碼很容易被攔截。該方案也同樣沒有對伺服器傳回的資訊提供保護。
現存的浏覽器儲存認證資訊直到标簽頁或浏覽器被關閉，或者使用者清除曆史記錄。HTTP沒有為伺服器提供一種方法訓示用戶端丢棄這些被緩存的密鑰。這意味着服務
器端在使用者不關閉浏覽器的情況下，并沒有一種有效的方法來讓使用者登出。
OAuth對于Http來說，就是放在Authorization header中的不是使用者名密碼， 而是一個token。微軟的Skydrive就是使用這樣的方式。
digest authentication（HTTP1.1提出的基本認證的替代方法）
這個認證可以看做是基本認證的增強版本，不包含密碼的明文傳遞。
引入了一系列安全增強的選項；“保護品質”(qop)、随機數計數器由用戶端增加、以及客戶生成的随機數。
在HTTP摘要認證中使用 MD5 加密是為了達成"不可逆的"，也就是說，當輸出已知的時候，确定原始的輸入應該是相當困難的。如果密碼本身太過簡單，也許可以
通過嘗試所有可能的輸入來找到對應的輸出（窮舉攻擊），甚至可以通過字典或者适當的查找表加快查找速度。
示例及說明
下面的例子僅僅涵蓋了“auth”保護品質的代碼，因為在撰寫期間，所知道的隻有Opera和Konqueror網頁浏覽器支援“auth-int”（帶完整性保護的認證）。
用戶端請求一個需要認證的頁面，但是不提供使用者名和密碼。通常這是由于使用者簡單的輸入了一個位址或者在頁面中點選了某個超連結。
伺服器傳回401 "Unauthorized" 響應代碼，并提供認證域(realm)，以及一個随機生成的、隻使用一次的數值，稱為密碼随機數 nonce。
此時，浏覽器會向使用者提示認證域(realm)（通常是所通路的計算機或系統的描述），并且提示使用者名和密碼。使用者此時可以選擇取消。
一旦提供了使用者名和密碼，用戶端會重新發送同樣的請求，但是添加了一個認證頭包括了響應代碼。
注意：用戶端可能已經擁有了使用者名和密碼，是以不需要提示使用者，比如以前存儲在浏覽器裡的。
用戶端請求 (無認證)：
伺服器響應：
用戶端請求 (使用者名 "Mufasa", 密碼 "Circle Of Life")：
伺服器響應：
response 值由三步計算而成。當多個數值合并的時候，使用冒号作為分割符：
1、對使用者名、認證域(realm)以及密碼的合并值計算 MD5 哈希值，結果稱為 HA1。
2、對HTTP方法以及URI的摘要的合并值計算 MD5 哈希值，例如，"GET" 和 "/dir/index.html"，結果稱為 HA2。
3、對HA1、伺服器密碼随機數(nonce)、請求計數(nc)、用戶端密碼随機數(cnonce)、保護品質(qop)以及 HA2 的合并值計算 MD5 哈希值。結果即為用戶端提供的
response 值。
因為伺服器擁有與用戶端同樣的資訊，是以伺服器可以進行同樣的計算，以驗證用戶端送出的 response 值的正确性。在上面給出的例子中，結果是如下計算的。
（MD5()表示用于計算MD5哈希值的函數；“”表示接下一行；引号并不參與計算）
此時用戶端可以送出一個新的請求，重複使用伺服器密碼随機數(nonce)（伺服器僅在每次“401”響應後發行新的nonce），但是提供新的用戶端密碼随機數(cnonce)。在後續的請求中，十六進制請求計數器(nc)必須比前一次使用的時候要大，否則攻擊者可以簡單的使用同樣的認證資訊重放老的請求。由伺服器來確定在每個發出的密碼随機數nonce時，計數器是在增加的，并拒絕掉任何錯誤的請求。顯然，改變HTTP方法和/或計數器數值都會導緻不同的 response值。
伺服器應當記住最近所生成的伺服器密碼随機數nonce的值。也可以在發行每一個密碼随機數nonce後，記住過一段時間讓它們過期。如果用戶端使用了一個過期的值，伺服器應該響應“401”狀态号，并且在認證頭中添加stale=TRUE，表明用戶端應當使用新提供的伺服器密碼随機數nonce重發請求，而不必提示使用者其它使用者名和密碼。
Cookie認證機制：使用者輸入使用者名和密碼發起請求，伺服器認證後給每個Session配置設定一個唯一的JSESSIONID，并通過Cookie發送給用戶端。
當用戶端發起新的請求的時候，将在Cookie頭中攜帶這個JSESSIONID。這樣伺服器能夠找到這個用戶端對應的Session。預設的，當我們關閉浏覽器的時候，用戶端cookie會被删除，可以通過修改cookie 的expire time使cookie在一定時間内有效。但是伺服器端的session不會被銷毀，除非通過invalidate或逾時。
常用的Token Auth（和Cookie Auth差別不大）：
首次登陸，使用者名和密碼驗證過之後，将sessionId儲存在token中，或者将一個key儲存在token中，key的值可以設定為使用者唯一性的資訊(賬号/密碼/身份認證機制(電話号/身份證号/支付寶賬号/銀行卡資訊)...)；當然我們在程式中的實作是儲存UUID作為ticket。
設定token的有效期，并儲存在伺服器資料庫中；
伺服器将這個token值傳回給用戶端，用戶端拿到 token 值之後，将 token 儲存在 cookie 中，以後用戶端再次發送網絡請求(一般不是登入請求)的時候,就會将這個 token 值附帶到參數中發送給伺服器。伺服器接收到用戶端的請求之後,會取出token值與儲存在本地(資料庫)中的token值做對比!
如果兩個 token 值相同 :說明使用者登入成功過!目前使用者處于登入狀态!如果沒有這個token或者過期，則設定token為無效，并讓使用者重新登入。
這種方式在用戶端變化不大，也要利用cookie，改動的是伺服器端
過去：通過sessionId查找Tomcat伺服器記憶體中是否有sessionId對應的session存在，若存在，則表示登陸過，然後從session找出使用者資訊；
現在：通過token查找資料庫中是否有相同的token，并且token要處于有效期前，有的話通過token在資料庫中找出使用者資訊，否則重新登入，(其實還包括sessionId的驗證，因為jsp預設建立session)。
如果覺得查詢資料庫比較耗時，可以用memcache或者redis緩存一下。
首先說明一下session何時會被建立：
1、 請求JSP頁面時自動建立session，利用request.getSession(true)；語句
原因：
由于HTTP是無狀态協定，這意味着每次用戶端檢索網頁時，都要單獨打開一個伺服器http連接配接，如果我同一個浏覽器，不同頁面打開你的首頁10次，那就要進行10次連接配接和斷開(TCP3次握手，4次揮手)，浪費系統資源，http提供了一種長連接配接，keep-alive，相同會話的不同請求可以用同一連接配接，故jsp預設建立session。而session的建立過程中會自動将sessionId寫入cookie的JSESSIONID中的，這樣，隻要不關閉浏覽器，你在同一網站的任意網頁跳轉，由于每次請求都會攜帶同一個sessionId，不會重新建立新的會話，防止建立多個會話浪費系統資源。
否則：黑客利用幾台主機，瘋狂的點選某一個JSP頁面，如果每次點選都建立一個新的會話，可能使伺服器崩潰。
例子：
登入函數：
登入首頁：
其中并沒有利用session的語句，但是主界面，當還沒有登入時：
可見有一個JSESSIONID，并且點選其他頁面并沒有開啟新的JSESSIONID。但是換一個浏覽器就會産生新的JSESSIONID，因為不同浏覽器的會話緩存是不可以互相用的
登入以後還是這個JSESSIONID：
Session的銷毀隻有三種方式：
1.調用了session.invalidate()方法
2.session過期（逾時）
3.伺服器重新啟動
單個JSP頁面禁用session方式
在servlet中，隻要代碼不調用Session相關的API就不會建立session
request.getSession() 等價于 request.getSession(true)
這兩個方法的作用是相同的，查找請求中是否有關聯的JSESSIONID，如果有則傳回這個号碼所對應的session對象，如果沒有則生成一個新的session對象。是以說，通過此方法是一定可以獲得一個session對象。
request.getSession(false) 查找請求中是否有關聯的JSESSIONID号，如果有則傳回這個号碼所對應的session對象，如果沒有則傳回一個null。
注意在建立session的過程中，sessionId是自動寫入cookie的JSESSIONID中的，如果禁用cookie，則通過url回傳
參考的頭條項目：
JSESSIONID和token(即ticket）同時存在，盡量不往session裡放東西，将使用者主鍵，過期時間等都存到和ticket一起的表中，優點：1.減少記憶體占用；2.Tomcat預設30分鐘session銷毀，采用token可以長時間保持登入狀态，但可能就不是這一個session了；3.除了JSESSIONID驗證一緻性，增加一個token驗證，防止黑客暴力破解JSESSIONID，但黑客可以獲得JSESSIONID，估計獲得token也不難，隻是會麻煩一點。
牛客網：
淘寶網：
都用了token和session（NOWCODERCLINETID和cookie2，這個隻是猜測），隻是不是直接儲存JSESSIONID，改名字了，如果攻擊者不分析站點，就不能猜到Session名稱，阻擋部分攻擊。
真正的應用：JWT
通過token可以将使用者的基本資訊(非隐私的，比如UserId，過期時間，生成的随機key等)全部加密簽名後放入token中，進而伺服器端不需要儲存使用者登入資訊，大大減輕伺服器壓力。使用者認證完全靠token識别，通過簽名來保證token沒有被修改過（隻有伺服器才知道秘鑰，比如常見的非對稱加密算法），是伺服器下發的token。在後續請求中，服務端隻需要對使用者請求中包含的token進行解碼，驗證使用者登入是否過期。
很多大型網站也都在用，比如 Facebook，Twitter，Google+，Github 等等，比起傳統的身份驗證方法，Token 擴充性更強，也更安全點，非常适合用在 Web 應用或者移動應用上。
Token Auth優點：
減輕伺服器壓力：通過token可以将使用者的基本資訊(非隐私的，比如UserId，過期時間，生成的随機key等)全部加密簽名後放入token中，進而伺服器端不需要儲存使用者登入資訊，大大減輕伺服器壓力。使用者認證完全靠token識别，通過簽名來保證token沒有被修改過（隻有伺服器才知道秘鑰，比如常見的非對稱加密算法），是伺服器下發的token。
支援跨域通路：因為伺服器并沒有儲存登入狀态，完全靠簽名的token識别，那麼另一個網站隻要有對應的私鑰，就可以對token驗證，前提是傳輸的使用者認證資訊通過HTTP頭傳輸；
更适用CDN: 可以通過内容分發網絡請求你服務端的所有資料（如：javascript，HTML,圖檔等），因為不需要同步伺服器上的登入狀态資訊；
性能更好: 因為從token中可以獲得userId，不用查詢登入狀态表；
詳細
但是都不能很好的預防會話劫持
Tomcat提供Realm支援。
Tomcat使用Realm使某些特定的使用者組具有通路某些特定的Web應用的權限，而沒有權限的使用者不能通路這個應用。
Tomcat提供了三種不同Realm對通路某個Web應用程式的使用者進行相應的驗證。
1、JDBCRealm，這個Realm将使用者資訊存在資料庫裡，通過JDBC從資料庫中獲得使用者資訊并進行驗證。
2、JNDIRealm，将使用者資訊存在基于LDAP等目錄服務的伺服器裡，通過JNDI技術從LDAP伺服器中擷取使用者資訊并進行驗證。
3、MemoryRealm，将使用者資訊存在一個xml檔案中，對使用者進行驗證時，将會從相應的xml檔案中提取使用者資訊。manager(Tomcat提供的一個web應用程式)應用在進行驗證時即使用此種Realm。Realm類似于Unix裡面的group。在Unix中，一個group對應着系統的一定資源，某個group不能通路不屬于它的資源。Tomcat用Realm來對不同的應用(類似系統資源)賦給不同的使用者(類似group)。沒有權限的使用者則不能通路這個應用。
HTTPS（HTTP over SSL，實際上是在原有的 HTTP 資料外面加了一層 SSL 的封裝。HTTP 協定原有的 GET、POST 之類的機制，基本上原封不動），是以安全為目标的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎是SSL，是以加密的詳細内容請看SSL。
對稱加密：密鑰隻有一個，加密解密為同一個密碼，且加解密速度快，典型的對稱加密算法有DES、AES等。
非對稱加密：密鑰成對出現（且根據公鑰無法推知私鑰，根據私鑰也無法推知公鑰），加密解密使用不同密鑰（公鑰加密需要私鑰解密，私鑰加密需要公鑰解密），相對對稱加密速度較慢，典型的非對稱加密算法有RSA、DSA等。
用戶端産生的密鑰隻有用戶端和伺服器端能得到；
加密的資料隻有用戶端和伺服器端才能得到明文；
用戶端到服務端的通信是安全的。
SSL/TLS協定希望達到：
（1） 所有資訊都是加密傳播，第三方無法竊聽。
（2） 具有校驗機制，一旦被篡改，通信雙方會立刻發現。
（3） 配備身份證書，防止身份被冒充。
1994年，NetScape公司設計了SSL協定（Secure Sockets Layer）的1.0版，但是未釋出。
1995年，NetScape公司釋出SSL 2.0版，很快發現有嚴重漏洞。
1996年，SSL 3.0版問世，得到大規模應用。
1999年，網際網路标準化組織ISOC接替NetScape公司，釋出了SSL的更新版TLS 1.0版。
2006年和2008年，TLS進行了兩次更新，分别為TLS 1.1版和TLS 1.2版。最新的變動是2011年TLS 1.2的修訂版。
目前，應用最廣泛的是TLS 1.0，接下來是SSL 3.0。但是，主流浏覽器都已經實作了TLS 1.2的支援。
TLS 1.0通常被标示為SSL 3.1，TLS 1.1為SSL 3.2，TLS 1.2為SSL 3.3。
SSL/TLS協定的基本思路是采用公鑰加密法，也就是說，用戶端先向伺服器端索要公鑰，然後用公鑰加密資訊，伺服器收到密文後，用自己的私鑰解密。
如何保證公鑰不被篡改？
解決方法：将公鑰放在數字證書中。隻要證書是可信的，公鑰就是可信的。
公鑰加密計算量太大，如何減少耗用的時間？
解決方法：每一次對話（session），用戶端和伺服器端都生成一個"對話密鑰"（session key），用它來加密資訊。由于"對話密鑰"是對稱加密，是以運算速度非常快，而伺服器公鑰隻用于加密"對話密鑰"本身，這樣就減少了加密運算的消耗時間。即在用戶端與伺服器間傳輸的資料是通過使用對稱算法（如 DES 或 RC4）進行加密的。
是以，SSL/TLS協定的基本過程是這樣的：
（1） 用戶端向伺服器端索要并驗證公鑰。
（2） 雙方協商生成"對話密鑰"。
（3） 雙方采用"對話密鑰"進行加密通信。
上面過程的前兩步，又稱為"握手階段"（handshake）。
"握手階段"涉及四次通信，我們一個個來看。
1 用戶端送出請求（ClientHello）
首先，用戶端（通常是浏覽器）先向伺服器發出加密通信的請求，這被叫做ClientHello請求。
在這一步，用戶端主要向伺服器提供以下資訊。
（1） 支援的協定版本，比如TLS 1.0版。
（2） 一個用戶端生成的随機數，稍後用于生成"對話密鑰"。
（3） 支援的加密方法，比如RSA公鑰加密。
（4） 支援的壓縮方法。
這裡需要注意的是，用戶端發送的資訊之中不包括伺服器的域名。也就是說，理論上伺服器隻能包含一個網站，否則會分不清應該向用戶端提供哪一個網站的數字證書。這就是為什麼通常一台伺服器隻能有一張數字證書的原因。
對于虛拟主機的使用者來說，這當然很不友善。2006年，TLS協定加入了一個Server Name Indication擴充，允許用戶端向伺服器提供它所請求的域名。
2 伺服器回應（SeverHello）
伺服器收到用戶端請求後，向用戶端發出回應，這叫做SeverHello。伺服器的回應包含以下内容。
（1） 确認使用的加密通信協定版本，比如TLS 1.0版本。如果浏覽器與伺服器支援的版本不一緻，伺服器關閉加密通信。
（2） 一個伺服器生成的随機數，稍後用于生成"對話密鑰"。
（3） 确認使用的加密方法，比如RSA公鑰加密。
（4） 伺服器證書。
除了上面這些資訊，如果伺服器需要确認用戶端的身份，就會再包含一項請求，要求用戶端提供"用戶端證書"。比如，金融機構往往隻允許認證客戶連入自己的網絡，就會向正式客戶提供USB密鑰，裡面就包含了一張用戶端證書。
3 用戶端回應
用戶端收到伺服器回應以後，首先驗證伺服器證書。如果證書不是可信機構頒布、或者證書中的域名與實際域名不一緻、或者證書已經過期，就會向通路者顯示一個警告，由其選擇是否還要繼續通信。
如果證書沒有問題，用戶端就會從證書中取出伺服器的公鑰。然後，向伺服器發送下面三項資訊。
（1） 一個随機數。該随機數用伺服器公鑰加密，防止被竊聽。
（2） 編碼改變通知，表示随後的資訊都将用雙方商定的加密方法和密鑰發送。
（3） 用戶端握手結束通知，表示用戶端的握手階段已經結束。這一項同時也是前面發送的所有内容的hash值，用來供伺服器校驗。
上面第一項的随機數，是整個握手階段出現的第三個随機數，又稱"pre-master key"。有了它以後，用戶端和伺服器就同時有了三個随機數，接着雙方就用事先商定的加密方法，各自生成本次會話所用的同一把"會話密鑰"。
至于為什麼一定要用三個随機數，來生成"會話密鑰"：
"不管是用戶端還是伺服器，都需要随機數，這樣生成的密鑰才不會每次都一樣。由于SSL協定中證書是靜态的，是以十分有必要引入一種随機因素來保證協商出來的密鑰的随機性。
對于RSA密鑰交換算法來說，pre-master-key本身就是一個随機數，再加上hello消息中的随機，三個随機數通過一個密鑰導出器最終導出一個對稱密鑰。
pre master的存在在于SSL協定不信任每個主機都能産生完全随機的随機數，如果随機數不随機，那麼pre master secret就有可能被猜出來，那麼僅适用pre master secret作為密鑰就不合适了，是以必須引入新的随機因素，那麼用戶端和伺服器加上pre master secret三個随機數一同生成的密鑰就不容易被猜出了，一個僞随機可能完全不随機，可是是三個僞随機就十分接近随機了，每增加一個自由度，随機性增加的可不是一。"
此外，如果前一步，伺服器要求用戶端證書，用戶端會在這一步發送證書及相關資訊。
4 伺服器的最後回應
伺服器收到用戶端的第三個随機數pre-master key之後，計算生成本次會話所用的"會話密鑰"。然後，向用戶端最後發送下面資訊。
（1）編碼改變通知，表示随後的資訊都将用雙方商定的加密方法和密鑰發送。
（2）伺服器握手結束通知，表示伺服器的握手階段已經結束。這一項同時也是前面發送的所有内容的hash值，用來供用戶端校驗。
至此，整個握手階段全部結束。接下來，用戶端與伺服器進入加密通信，就完全是使用普通的HTTP協定，隻不過用"會話密鑰"加密内容。
需要一對密鑰，一個是私人密鑰，另一個則是公開密鑰。這兩個密鑰是數學相關，用某使用者密鑰加密後所得的資訊，隻能用該使用者的解密密鑰才能解密。如果知道了其中一個，并不能計算出另外一個。是以如果公開了一對密鑰中的一個，并不會危害到另外一個的秘密性質。稱公開的密鑰為公鑰；不公開的密鑰為私鑰。
如果加密密鑰是公開的，這用于客戶給私鑰所有者上傳加密的資料，這被稱作為公開密鑰加密（狹義）。例如，網絡銀行的客戶發給銀行網站的操作資訊的加密資料，采用公鑰加密。
如果解密密鑰是公開的，用私鑰加密的資訊，可以用公鑰對其解密，用于客戶驗證持有私鑰一方釋出的資料或檔案是完整準确的，接收者由此可知這條資訊确實來自于擁有私鑰的某人，這被稱作數字簽名，公鑰的形式就是數字證書。
每個人都有一對“鑰匙”（數字身份），其中一個隻有她/他本人知道（私鑰），另一個公開的（公鑰）。簽名的時候用私鑰，驗證簽名的時候用公鑰。又因為任何人都可以落款申稱她/他就是使用者本人，是以公鑰必須向接受者信任的人（身份認證機構）來注冊。注冊後身份認證機構給使用者發一數字證書。對檔案簽名後，使用者把此數字證書連同檔案及簽名一起發給接受者，接受者向身份認證機構求證是否真地是用使用者的密鑰簽發的檔案。
在中國，數字簽名是具法律效力的，正在被普遍使用。
使用最廣泛的是RSA算法
1977年，三位數學家Rivest、Shamir 和 Adleman 設計了一種算法，可以實作非對稱加密。這種算法用他們三個人的名字命名，叫做RSA算法。
這種算法非常可靠，密鑰越長，它就越難破解。根據已經披露的文獻，目前被破解的最長RSA密鑰是768個二進制位。也就是說，長度超過768位的密鑰，還無法破解（至少沒人公開宣布）。是以可以認為，1024位的RSA密鑰基本安全，2048位的密鑰極其安全。
"對極大整數做因數分解的難度決定了RSA算法的可靠性。換言之，對一極大整數做因數分解愈困難，RSA算法愈可靠。
假如有人找到一種快速因數分解的算法，那麼RSA的可靠性就會極度下降。但找到這樣的算法的可能性是非常小的。今天隻有短的RSA密鑰才可能被暴力破解。到2008年為止，世界上還沒有任何可靠的攻擊RSA算法的方式。
隻要密鑰長度足夠長，用RSA加密的資訊實際上是不能被解破的。"
RSA性能是非常低的，原因在于尋找大素數、大數計算、資料分割需要耗費很多的CPU周期，是以一般的HTTPS連接配接隻在握手時使用非對稱加密，通過握手交換對稱加密密鑰(其實隻有第三次通信，用戶端向伺服器發送随機數時用公鑰加密)，在之後的通信走對稱加密。
如果兩個正整數，除了1以外，沒有其他公因子，我們就稱這兩個數是互質關系（coprime）。比如，15和32沒有公因子，是以它們是互質關系。這說明，不是質數也可以構成互質關系。
關于互質關系，不難得到以下結論：
1. 任意兩個質數構成互質關系，比如13和61。
2. 一個數是質數，另一個數隻要不是前者的倍數，兩者就構成互質關系，比如3和10。
3. 如果兩個數之中，較大的那個數是質數，則兩者構成互質關系，比如97和57。
4. 1和任意一個自然數是都是互質關系，比如1和99。
5. p是大于1的整數，則p和p-1構成互質關系，比如57和56。
6. p是大于1的奇數，則p和p-2構成互質關系，比如17和15。
任意給定正整數n，請問在小于等于n的正整數之中，有多少個與n構成互質關系？（比如，在1到8之中，有多少個數與8構成互質關系？）
計算這個值的方法就叫做歐拉函數，以φ(n)表示。在1到8之中，與8形成互質關系的是1、3、5、7，是以 φ(n) = 4。
因為任意一個大于1的正整數，都可以寫成一系列質數的積。
歐拉函數的通用計算公式
歐拉定理
模反元素
詳細看：
http://www.ruanyifeng.com/blog/2013/06/rsa_algorithm_part_one.html
假設愛麗絲要與鮑勃進行加密通信，她該怎麼生成公鑰和私鑰呢？
第一步，随機選擇兩個不相等的質數p和q。
愛麗絲選擇了61和53。（實際應用中，這兩個質數越大，就越難破解。）
第二步，計算p和q的乘積n。
愛麗絲就把61和53相乘。
n = 61×53 = 3233
n的長度就是密鑰長度。3233寫成二進制是110010100001，一共有12位，是以這個密鑰就是12位。實際應用中，RSA密鑰一般是1024位，重要場合則為2048位。
第三步，計算n的歐拉函數φ(n)。
根據公式：
φ(n) = (p-1)(q-1)
愛麗絲算出φ(3233)等于60×52，即3120。
第四步，随機選擇一個整數e，條件是1< e < φ(n)，且e與φ(n) 互質。
愛麗絲就在1到3120之間，随機選擇了17。（實際應用中，常常選擇65537。）
第五步，計算e對于φ(n)的模反元素d。
所謂"模反元素"就是指有一個整數d，可以使得ed被φ(n)除的餘數為1。
ed ≡ 1 (mod φ(n))
這個式子等價于
ed - 1 = kφ(n)
于是，找到模反元素d，實質上就是對下面這個二進制一次方程求解。
ex + φ(n)y = 1
已知 e=17, φ(n)=3120，
17x + 3120y = 1
這個方程可以用"擴充歐幾裡得算法"求解，此處省略具體過程。總之，愛麗絲算出一組整數解為 (x,y)=(2753,-15)，即 d=2753。
至此所有計算完成。
第六步，将n和e封裝成公鑰，n和d封裝成私鑰。
在愛麗絲的例子中，n=3233，e=17，d=2753，是以公鑰就是 (3233,17)，私鑰就是（3233, 2753）。
實際應用中，公鑰和私鑰的資料都采用ASN.1格式表達（執行個體）。
結論：如果n可以被因數分解，d就可以算出，也就意味着私鑰被破解。
大整數的因數分解，是一件非常困難的事情。目前，除了暴力破解，還沒有發現别的有效方法。
http://www.ruanyifeng.com/blog/2013/07/rsa_algorithm_part_two.html
在大家的觀念裡，出于安全考慮，浏覽器不會在本地儲存HTTPS緩存。 實際上， 隻要在HTTP頭中使用特定指令，HTTPS是可以緩存的。
Microsoft 項目經理Eric Lawrence 寫道：
比如，如果頭指令是Cache-Control:max-age=600，那麼HTTPS的網頁就将被IE緩存10分鐘，IE的緩存政策與是否使用HTTPS協定無線。其它浏覽器也有類似的操作方法。
Firefox預設隻在記憶體中緩存HTTPS。但是，隻要頭指令中有Cache-Control:Public，緩存就會被寫到硬碟上。下面的圖檔顯示，Firefox的硬碟緩存中有HTTPS内容，頭指令正是Cache-Control:Public。
雖然無法直接從HTTPS資料中讀取Cookie和查詢字元串，但是你仍然需要使它們的值變得難以預測。
比如，曾經有一家英國銀行，直接使用順序排列的數值表示session id:
黑客可以先注冊一個賬戶，找到這個cookie，看到這個值的表示方法。然後，改動cookie，進而劫持其他人的session id。至于查詢字元串，也可以通過類似方式洩漏。