腳本之家服務(wù)器常用軟件

快捷導(dǎo)航

在Windows服務(wù)器上啟用TLS 1.2及TLS 1.2基本原理介紹

更新時間：2017年04月11日 21:57:57 投稿：mdxy-dxy

最近由于Chrome40不再支持SSL 3.0了，GOOGLE認(rèn)為SSL3.0已經(jīng)不再安全了。所以也研究了一下SSL TLS加密,給大家分享一下

首先在這個網(wǎng)站上測試一下自己的服務(wù)器究竟處于什么水平。

https://www.ssllabs.com/ssltest/

測試結(jié)果顯示是支持SSL3.0的并且不支持TLS 1.2。證書使用SHA1簽名算法不夠強(qiáng)。這點(diǎn)比較容易接受，因為Windows服務(wù)器默認(rèn)并沒有開啟TLS1.2。

要提高服務(wù)器的評級，有3點(diǎn)需要做。

使用SHA256簽名算法的證書。

禁用SSL3.0，啟用TLS1.2

禁用一些弱加密算法。

由于目前服務(wù)器使用的證書是近3年前購買的，正好需要重新購買，順便就可以使用SHA256簽名算法來買新的證書就可以了。在生產(chǎn)環(huán)境部署之前，先用測試機(jī)測試一下。

根據(jù)這篇文章中的3條命令把證書頒發(fā)機(jī)構(gòu)的簽名算法升級上去。測試環(huán)境是Windows2012 R2,默認(rèn)的簽名算法是SHA1

UpgradeCertification Authority to SHA256

http://blogs.technet.com/b/pki/archive/2013/09/19/upgrade-certification-authority-to-sha256.aspx

certutil -setreg ca\csp\CNGHashAlgorithm SHA256
net stop certsvc
net start certsvc

然后，在服務(wù)器中添加注冊表鍵值并重啟已啟用TLS1.2和禁用SSL3.0

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS1.2\Server\Enabled REG_DWORD類型設(shè)置為1.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL3.0\Server Enabled REG_DWORD類型設(shè)置為0.

重新啟動服務(wù)器，是設(shè)置生效。

由于測試機(jī)沒有公網(wǎng)地址，所以去下載個測試工具，方便測試。

http://www.bolet.org/TestSSLServer/

可以下載到EXE或者JAVA版本的測試工具，方便的在內(nèi)網(wǎng)測試服務(wù)器支持的加密方式。

測試了一下，發(fā)現(xiàn)TLS1.2沒有啟用。

難道是啟用方法不對?于是開始檢查各種服務(wù)器的日志，也的確發(fā)現(xiàn)了TLS1.2不能建立的報錯了。

網(wǎng)上查了很多文章，也沒有說什么解決辦法。后來換了下證書，用回SHA1的證書，TLS1.2就能顯示成功啟用了。

難道是證書有問題，于是就各種搜索SHA1證書和SHA256證書的區(qū)別，同時也測試了一些別人的網(wǎng)站，結(jié)果發(fā)現(xiàn)別人用SHA256證書也能支持TLS1.2. 難道是我的CA有問題？

又研究了幾天，也測試了2008 R2的機(jī)器還是同樣的問題。正好新買的公網(wǎng)證書也下來了。就拿這張證書先放到測試服務(wù)器上測試，結(jié)果還是不行。但是別人的服務(wù)器的確可以啊。

在此期間發(fā)現(xiàn)兩篇比較好的文章，用Powershell來幫助我們啟用TLS1.2以及如何設(shè)定服務(wù)器的加密算法順序。

Setupyour IIS for SSL Perfect Forward Secrecy and TLS 1.2

https://www.hass.de/content/setup-your-iis-ssl-perfect-forward-secrecy-and-tls-12

EnablingTLS 1.2 on IIS 7.5 for 256-bit cipher strength

http://jackstromberg.com/2013/09/enabling-tls-1-2-on-iis-7-5-for-256-bit-cipher-strength/

那么問題究竟出在哪呢？可能的問題，SHA256證書有問題？服務(wù)器不支持TLS1.2？然后根據(jù)Windows日志中的錯誤繼續(xù)查找，都沒能找到什么有用的信息。

于是求助朋友，朋友發(fā)來一段信息。

TLS 1.2introduced signature algorithms extension where the client advertises supportedsignature and hash algorithm combinations. When the client offers TLS1.2 without signature algorithms extension,schannel server assumes that this client only understands SHA1. If the schannelserver only has a SHA256 certificate, it will terminate the handshake. However,the same client offering TLS≤1.1 will succeed.

同時也提到了RFC5246中的一些信息。

http://www.ietf.org/rfc/rfc5246.txt

If the clientdoes not send the signature_algorithms extension, the

server MUST do the following:

- Ifthe negotiated key exchange algorithm is one of (RSA, DHE_RSA,

DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA),behave as if client had

sent the value {sha1,rsa}.

- Ifthe negotiated key exchange algorithm is one of (DHE_DSS,

DH_DSS), behave as if the client had sentthe value {sha1,dsa}.

- Ifthe negotiated key exchange algorithm is one of (ECDH_ECDSA,

ECDHE_ECDSA), behave as if the client hadsent value {sha1,ecdsa}.

Note: this is a change from TLS 1.1 wherethere are no explicit

rules, but as a practical matter one canassume that the peer

supports MD5 and SHA-1.

Note: this extension is not meaningful forTLS versions prior to 1.2.

Clients MUST NOT offer it if they areoffering prior versions.

However, even if clients do offer it, therules specified in [TLSEXT]

require servers to ignore extensions they donot understand.

Servers MUST NOT send this extension. TLS servers MUST support

receiving this extension.

When performing session resumption, thisextension is not included in

Server Hello, and the server ignores theextension in Client Hello

(if present).

這和我遇到的問題完全符合啊，難道是客戶端沒有發(fā)送簽名算法擴(kuò)展？于是用IE試了下訪問網(wǎng)站，發(fā)現(xiàn)是可以的，于是抓包看一下，用的協(xié)議是TLS1.2。證明TLS1.2在服務(wù)器上是已經(jīng)啟用的了。有client hello并且服務(wù)器也回應(yīng)了serverhello。