系統管理員如何快速高效的部署SSL和TLS？
1 私鑰和證書
在TLS中，所有安全性都以伺服器的加密身份開始，這就需要一個強大的私鑰來防止攻擊者進行模擬攻擊。同樣重要的是擁有一個有效和強大的證書，它會授予私鑰來代表一個特定的主機名。
1.1使用2048位私鑰
對於大多數網站都來說，由2048位RSA密鑰提供的安全性就已經足夠了。 由於RSA公鑰演算法應用廣泛，從而使得它成為安全的默認選擇。對於2048位的RSA密鑰來說，能夠提供大約112位密鑰。如果你想要更高的安全性， RSA密鑰則不能很好地進行擴展。比如，要獲得128位的密鑰，就需要3072位的RSA密鑰，這顯然運行較慢。 橢圓曲線數字簽名演算法ECDSA顯示為你提供了更好的安全性和更好的性能。以ECDSA256為例,，ECDSA密鑰提供了128位的密鑰。
1.2保護私鑰
為了保護你的私鑰產，我們提供了以下5條建議：
（1）要在具有足夠熵的可信計算機上生成私鑰。
（2）從一開始就要為密鑰設置密碼保護，以防止在存儲到備份系統中時受到攻擊。私鑰密碼在實際運行中不會有太大的安全保障，因為攻擊者完全可以隨時從進程內存中檢索密鑰。利用硬體設備（硬體安全模塊或HSM），即使在伺服器受損的情況下也可以保護私鑰，但是這些設備是昂貴的，因此僅適用於對安全有嚴格安全性要求的機構。
（3）被攻擊後，撤銷舊證書並生成新密鑰。
（4）每年更新證書，最好你的設備可以自動執行此過程，因此具有較短使用周期的證書在實踐中更為安全。
（5）除非特殊情況，否則每當獲得新證書時，就應該生成相應的新私鑰。
1.3確保證書覆蓋所使用的網站
確保你的證書覆蓋你所使用的網站，避免無效的證書警告。
即使你只有一個域名，你也應確保證書與www前綴有關，例如，http://example.com和Example Domain。安全的Web伺服器的每個DNS名稱都應該配置一個有效的證書。
還有訪問私鑰的人越少越好，要注意的是，證書共享會創建一個綁定，可以將漏洞從一個網站或伺服器傳輸到使用相同證書的所有其他站點和伺服器（即使底層私鑰不同）。
1.4從可靠的CA獲取證書
選擇從可靠的CA獲取證書，選擇CA時，請注意以下5方面：
（1）所有CA的安全狀態都要經過定期審核，建議你查看不同CA的安全歷史，更重要的是，他們如何對攻擊作出應對。
（2）選擇那些把CA作為重要業務的機構
（3）你選擇的CA應提供證書吊銷列表（CRL）和在線證書狀態協議（OCSP）撤銷的支持，另外，你還應該考慮是否需要擴展驗證（E）證書，大多數網站目前都使用RSA，不過ECDSA在未來可能會變得更加重要。
（4）如果你需要大量證書並在複雜的環境中運行，請選擇能為你提供良好的CA管理工具的機構。
（5）選擇能為提供各種功能支持的CA。
1.5使用強大的證書籤名演算法
證書安全性取決於用於簽署證書的私鑰的強度及簽名中使用的哈希函數的強度。原來大多數證書都依賴於SHA1散列函數，不過現在已經證實這是不安全的。因此，目前的趨勢是正在向SHA256轉型。截止2016年底，SHA1證書將不再被網站支持。
2 配置
使用正確的TLS伺服器配置，就可以確保將登錄憑證正確地呈現給站點的訪問者，使用安全的加密原語，能減少所有已知的漏洞。
2.1使用完整的證書鏈
在大多數部署中，只有伺服器證書需要兩個或多個證書來建立完整的信任鏈。如果只具有有效證書但沒有必要的中間證書時，伺服器就會發生常見的配置問題。為避免這種情況，就需使用CA提供給你的所有證書。
無效的證書鏈會讓伺服器證書無效並導致瀏覽器發出安全警告，實際上，這個問題有時候很難判斷，因為有些瀏覽器可以重建不完整的鏈，而有些瀏覽器則不能重建。所有瀏覽器都傾向於緩存和重用中間證書。
2.2使用安全協議
SSL/TLS系列中有五種協議：SSL 2，SSL 3，TLS 1.0，TLS 1.1和TLS 1.2。SSL 2最不安全，請你不要使用。此協議版本設計的非常糟糕，即使它們位於完全不同的伺服器（DROWN攻擊）上也可以用來攻擊具有相同名稱的RSA密鑰和站點。
由於SSL 3已經非常老了，所以當與HTTP（POODLE攻擊）一起使用時，SSL 3非常不安全的，建議不要使用。
從理論上來講，TLS 1.0也不應該被使用，但在實踐中經常被使用。其主要弱點（BEAST）已在目前的瀏覽器中得到緩解，但其他問題仍然存在。
截至目前，TLS 1.1和 1.2都還沒有什麼安全問題，但只有 1.2提供了現代的加密演算法。所以TLS 1.2應該是被使用的主要協議，因為它是唯一提供現代認證加密（也稱為AEAD）的版本。不過從實際考慮，目前一些較老的客戶端仍支持TLS 1.0。 但是，建議大家還是儘快淘汰TLS 1.0。 例如，支付卡行業數據安全標準PCI DSS將要求所有接受信用卡付款的網站在2018年6月之前放棄對TLS 1.0的支持。
目前IETF正在對TLS 1.3進行緊鑼密鼓的研製，其目的是消除所有過時和不安全的功能，讓未來幾十年內的通信都處於安全狀態。
與之前版本類似，TLS 1.3協議可分為握手協議和記錄協議，前者負責密碼組件的協商以及安全信道的建立，後者則是在已建立的安全信道中傳輸秘密信息。TLS 1.3設計的第一個重要目標就是避免之前版本存在的缺陷，比如禁用RSA密鑰傳輸演算法、禁用一些安全性較弱的密碼原語如MD5的使用、不再支持重協商握手模式、握手消息採取了加密操作、實現了握手協議和記錄協議的密鑰分離、記錄層只能使用AEAD（Authenticated Encryption with Additional Data）認證加密模式……
2.3使用加密套件
要確保通信的安全，你必須首先確定能與通信對象直接進行通信並安全地交換數據。在SSL和TLS中，加密套件就是伺服器和客戶端所使用的加密演算法的組合，它明確了SSL握手階段和通信階段所應該採用的各種演算法。通常加密套件包含3種演算法，第一個是密鑰交換，這個會使用非對稱加密演算法來生成會話密鑰，因為非對稱演算法不會將重要數據在通信中傳輸；第二個是對稱加密演算法，主要是對傳輸的數據進行加密傳輸用的，如果性能允許，這裡可以不需要，因為非對稱加密演算法太耗性能，再者有些非對稱加密演算法有內容長度的限制，所以真正要傳輸的數據會使用對稱加密來進行加密；第三個是會話校驗演算法，為了防止握手本身被竄改（這裡極容易和證書籤名演算法混淆）。
不過目前要主要依靠提供強身份驗證和密鑰交換的演算法，使用至少128位加密的AEAD加密演算法套件。
不過有幾個過時的加密原語必須禁止使用：
（1）匿名Diffie-Hellman（ADH）套件不提供身份驗證。（2）NULL加密套件不提供加密。（3）導出加密套件在連接協商時不安全，但也可以針對更強大的套件（FREAK攻擊）的伺服器使用。（4）弱密碼（通常為40和56位）的套件使用可以輕鬆被攻擊。（5）RC4是不安全的。（6）3DES運行緩慢且易被攻擊。
使用以RSA和ECDSA鍵為對象的以下套件配置作為起點：
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHATLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHATLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384TLS_ECDHE_RSA_WITH_AES_128_CBC_SHATLS_ECDHE_RSA_WITH_AES_256_CBC_SHATLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384TLS_DHE_RSA_WITH_AES_128_GCM_SHA256TLS_DHE_RSA_WITH_AES_256_GCM_SHA384TLS_DHE_RSA_WITH_AES_128_CBC_SHATLS_DHE_RSA_WITH_AES_256_CBC_SHATLS_DHE_RSA_WITH_AES_128_CBC_SHA256TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
我們建議你先在臨時環境中測試你的TLS配置，只有確定一切正常工作時再進行協議的更改。請注意，以上只是一個通用列表，並不是所有系統（特別是較舊的）都支持所有套件，這就是為什麼要先進行測試。
上述示例配置使用的就是標準TLS套件名稱，但一些平台使用的是非標準名稱，例如，以下套件名稱將與OpenSSL一起使用：
ECDHE-ECDSA-AES128-GCM-SHA256ECDHE-ECDSA-AES256-GCM-SHA384ECDHE-ECDSA-AES128-SHAECDHE-ECDSA-AES256-SHAECDHE-ECDSA-AES128-SHA256ECDHE-ECDSA-AES256-SHA384ECDHE-RSA-AES128-GCM-SHA256ECDHE-RSA-AES256-GCM-SHA384ECDHE-RSA-AES128-SHAECDHE-RSA-AES256-SHAECDHE-RSA-AES128-SHA256ECDHE-RSA-AES256-SHA384DHE-RSA-AES128-GCM-SHA256DHE-RSA-AES256-GCM-SHA384DHE-RSA-AES128-SHADHE-RSA-AES256-SHADHE-RSA-AES128-SHA256DHE-RSA-AES256-SHA256
2.4選擇最佳加密套件
在SSL 3及更高版本的協議版本中，客戶端會先提交一系列支持的加密套件，伺服器從列表中選擇一個用於連接的套件。然而，並不是所有的伺服器都能執行此操作，有些會固定的從客戶端列表中選擇第一個支持的套件，所以伺服器主動選擇最佳可用加密套件對於實現最佳安全性至關重要。
2.5使用前向保密
前向保密(Forward Secrecy)，有時也稱為完美前向保密(Perfect Forward Secrecy)，是一種協議函數，可以實現不依賴伺服器私鑰的安全通信。它為客戶端和伺服器端提供了一種為會話創建共享密鑰的辦法，而這個密鑰不會暴露給任何監測數據交換的人（即便監測者能夠得到伺服器的私鑰，只要它只是個監測者而不是中間人）。使用ECDHE套件，以便通過網路瀏覽器進行前向保密。為了讓前向保密得到更廣泛的使用，你還應該使用DHE套件作為ECDHE的協商回退(fallback)方案。再次提醒，盡量避免使用RSA密鑰交換。
2.6使用強大的密鑰交換
對於密鑰交換，公共站點通常可以選擇經典的臨時的Diffie-Hellman密鑰交換（DHE）和橢圓曲線(ECC)的DH演算法。還有其他的密鑰交換演算法，但是它們通常都不安全。 RSA密鑰交換仍然很受歡迎，但不提供前向保密。
2015年，研究人員發現一個SSL加密安全漏洞LogJam，LogJam漏洞將影響任何支持DHE_EXPORT密碼的伺服器及所有瀏覽器，包括最新版的IE、Chrome、Firefox、Safari等。隨後他們評估稱學術派黑客可以破解768位的密鑰，而國家支持的黑客更可以突破1024位的密鑰。所以為了安全起見，如果部署DHE，至少要配置2048位的密鑰。一些較老的客戶端（例如Ja a 6）可能不支持這種高強度的加密。出於性能原因，大多數伺服器應該更喜歡ECDHE，它們更強大，運行更快。在這種情況下，橢圓曲線演算法secp256k1（也稱為P-256）就是一個很好的選擇。
2.7將威脅將至最低
近年來，對SSL和TLS發生了幾次嚴重的攻擊，在此，我們建議大家運行最新的軟體並遵循本問中的建議。
3 性能
雖然安全是本文所講的重點，但前提是要具備實用性的需要，否則我們不會為大家推薦的。通過正確配置以後，TLS運行可以相當快。使用最新的協議（例如HTTP/2），甚至可能比明文通信更快。
3.1避免一味的追求過高的安全性
使用太短的密碼肯定是不安全的，但使用太長的密碼也不一定安全，比如會導致操作的複雜。對於大多數網站來說，使用強於2048位的RSA密鑰以及使用強於256位的ECDSA密鑰會浪費CPU功耗，並可能會損害用戶體驗。類似地，增加臨時密鑰交換的強度對於DHE為2048位以及ECDHE為256位幾乎沒有什麼好處，使用高於128位的加密也沒有明顯的好處。
3.2使用會話重用機制
會話重用機制是一種性能優化技術，SSL 會話重用機制的原理就是在服務端緩存所有的會話，客戶端之後在每次和服務端握手時通過會話 ID完成會話重用機制，這是一種節省內存的機制。
3.3使用WAN優化和HTTP/2
其實TLS的運行性能的降低不是來自CPU進行高強度的加密操作，而是來自網路延遲。因為只有在TCP握手完成之後才能啟動TLS握手，除此之外，還需要進一步交換數據包，通常跨接很大的物理範圍。最小化延遲的最佳方法就是避免創建新的連接，換句話說，就是保持現有的連接時間足夠長（keep-alives）。另外，提供良好優化效果的其他技術還包括最新的協議（如HTTP / 2）和使用WAN優化。
3.4緩存公共內容
通過TLS進行通信時，瀏覽器可能會把所有流量都視為敏感數據。這樣，它們通常會使用內存來緩存某些資源，但一旦關閉瀏覽器，所有內容都可能會丟失。為了獲得性能提升並實現對某些資源的長期緩存，可以將公共資源（例如圖像）標記為公開。
3.5使用OCSP閉合
OCSP閉合(OCSP Stapling)是OCSP協議的擴展，這個技術節省了在客戶端和OCSP響應者之間的一個來回，可以直接從伺服器提供撤銷信息作為TLS握手的一部分。因此，客戶端不需要聯繫OCSP伺服器進行帶外驗證，並且總體TLS連接時間顯著減少。但並不是所有的網路伺服器都提供了OCSP閉合技術。
3.6使用快速加密原語
儘可能使用支持硬體加速AES的CPU，如果你真的想要進一步提高性能，請考慮使用ECDSA密鑰。
4 HTTP和應用安全
HTTP協議和應用交付平台在SSL誕生後快速發展。目前，應用交付平台的加密功能已經可以超過一般的秘鑰了。下面我們就列出了這些功能，以及安全使用它們的方法。
4.1加密一切
加密的問題可能是當今最大的安全問題之一，比如：
（1）沒有TLS的網站
（2）具有TLS但不執行TLS的站點
（3）混合了TLS和非TLS內容的網站，有時甚至在同一網頁內
（4）編程錯誤的網站會破壞TLS
4.2消除混合內容
混合內容頁面是通過TLS傳輸但是包含不通過TLS傳輸的資源（例如，JavaScript文件、圖像、CSS文件）的頁面。這樣的頁面非常不安全，這些不受保護的JavaScript資源會被中間人攻擊所利用，例如劫持整個用戶會話。即使你加密了整個網站，仍然可能會從第三方網站中檢索出未加密的一些資源。
4.3了解並信任第三方
多數網站都是通過從另一台伺服器下載的JavaScript代碼來激活的第三方服務比如Google Analytics。包含第三方代碼的網站會創建一個隱含的信任連接，有效地使對方完全控制你的網站。雖然第三方連接可能不是惡意的，但是這些服務背後的廠商可能被攻擊，比如，如果一個伺服器被攻擊，那攻擊者將自動訪問所有依賴該伺服器的站點。
如果你遵循第4.2的建議，至少你的第三方鏈接將被加密，從而避免MITM攻擊。目前子資源完整性（SRI）可用於第三方資源減少潛在的風險，它是一項安全功能，可讓瀏覽器驗證其抓取的文件 (例如，從一個 CDN) 是在沒有意外操作的情況下傳遞的。它的工作原理是允許您提供一個獲取的文件必須匹配的加密哈希。
4.4安全Cookie
為了在保持性能的前提下，實現安全，網站需要TLS，而且所有的Cookie在創建時都被明確標記為安全的。否則就有可能被MITM攻擊者利用，建議大家為你的Cookie添加加密完整性驗證。
4.5安全的HTTP壓縮
CRIME攻擊通過利用壓縮過程中的漏洞，可解密部分安全連接。而禁用TLS壓縮可防止這種攻擊。另外要注意，HTTP壓縮可能被TIME和BREACH攻擊利用。CRIME允許攻擊者恢復HTTP的請求頭,其中包含cookies和其他身份驗證數據,而BREACH著力於另一個方向——使用壓縮邊信道攻擊影響HTTP響應。與TLS壓縮不同，HTTP壓縮是必需的，不能關閉。因此，為了解決這些攻擊，需要對應用程序代碼進行更改。
TIME和BREACH攻擊並不容易實現，但如果能實現，其攻擊力相當於跨站請求偽造（CSRF）攻擊。
4.6如何配置使用 HTTP 嚴格傳輸安全(HSTS)
HTTP 嚴格傳輸安全（HSTS）是一種安全功能，web 伺服器通過它來告訴瀏覽器僅用 HTTPS 來與之通訊，而不是使用 HTTP。
要激活HSTS保護，你可以向你的網站添加一個新的響應頭。之後，支持HSTS的瀏覽器就會執行它。
簡單地說HSTS被激活後，它不允許與使用其網站進行任何不安全的通信。通過自動將所有明文鏈接轉換為安全的鏈接，來實現了這一目標。
建議大家添加對HSTS的支持，這是為TLS安全性做出的最重要的保障。為了獲得最佳安全效果，請考慮使用HSTS預載入，將HSTS配置嵌入到瀏覽器中。只要是在有效期內，瀏覽器都將直接強制性的發起HTTPS請求，但是問題又來了，有效期過了怎麼辦?其實不用為此過多擔心，因為HSTS Header存在於每個響應中，隨著用戶和網站的交互，這個有效時間時刻都在刷新，再加上有效期通常都被設置成了1年，所以只要用戶的前後兩次請求之間的時間間隔沒有超過1年，則基本上不會出現安全風險。
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
4.7部署內容安全策略
內容安全策略（CSP）是網站可以用來限制瀏覽器操作的安全機制。雖然最最初用意在於解跨站腳本攻擊 (XSS) 和數據注入等攻擊，但隨著CSP不斷發展，它目前不但可以支持TLS的安全性還能防止HTTPS混合內容錯誤並幫助改進HTTPS支持。
要部署CSP以防止第三方混合內容，請使用以下配置：
Content-Security-Policy: default-src https: unsafe-inline unsafe-eval; connect-src https: wss:
不過這不是部署CSP的最佳方法，為了方便本文的講解，我們不得不禁用某些默認安全功能。
4.8禁用敏感內容的緩存
由於使用基於雲的應用平台正在增加，所以為了讓所有敏感內容只讓接收方收到，你必須小心對敏感內容作出處理。
5正確部署前的驗證
也許在按著本文的方法在進行部署時，許多軟體和硬體配置都有了新的版本，建議大家先對自己的SSL / TLS做個全面評估，以確保運行的安全。推薦大家使用此鏈接Qualys SSL Labs進行測試。
本文翻譯自：ssllabs/research ，如若轉載，請註明來源於嘶吼： 系統管理員如何快速高效的部署SSL和TLS？ - 嘶吼 RoarTalk 更多內容請關注「嘶吼專業版」——Pro4hou
推薦閱讀：
※NO.21 波折的十二月-年終總結
※如何評價曉致的中間號技術？曉致中間號是什麼樣的一種業務模式？
※互聯網甲方公司和乙方公司安全工程師的薪資範圍大概是什麼樣的？
※暴雪遊戲存在嚴重遠程控制漏洞，數億用戶受影響
※PSAmsi：四兩撥千斤實現PowerShell代碼混淆隱藏