Ubuntu中的OpenSSL 1.0.1握手解決方法？

我遇到OpenSSL中的1.0.1一個嚴重的錯誤在Ubuntu 12.04：Ubuntu中的OpenSSL 1.0.1握手解決方法？

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=665452

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666051 < - 日2012年10月3日！

它的要點是，我可以連接到一些服務器，但不能連接到其他服務器。連接到谷歌工作：

的OpenSSL的s_client.First -connect mail.google.com:443 -debug -state -msg -CAfile /etc/ssl/certs/ca-certificates.crt

... 
Protocol : TLSv1.1 
Cipher : ECDHE-RSA-RC4-SHA 
Session-ID: 94DB1AC8531115C501434B16A5E9B735722768581778E4FEA4D9B19988551397 
Session-ID-ctx: 
Master-Key: 8694BF510CD7568CBAB39ECFD32D115C511529871F3030B67A4F7AEAF957D714D3E94E4CE6117F686C975EFF21FB8708 
Key-Arg : None 
PSK identity: None 
PSK identity hint: None 
SRP username: None 
TLS session ticket lifetime hint: 100800 (seconds) 
TLS session ticket: 
0000 - fb 52 d6 d3 3c a8 75 e1-1f 1d f6 23 ab ce 55 44 .R..<.u....#..UD 
0010 - 27 bf ad c4 7a 0d 83 c8-48 59 48 4b 39 bb 3c c7 '...z...HYHK9.<. 
0020 - 01 1e ad b3 13 de 65 d4-e8 ea e4 35 89 83 55 8e ......e....5..U. 
0030 - e4 d5 9f 60 58 51 33 9b-83 34 b9 35 3d 46 cb a3 ...`XQ3..4.5=F.. 
0040 - 35 7b 48 5d 7b 86 5c d5-a1 14 9d 8c 3e 93 eb fb 5{H]{.\.....>... 
0050 - ac 78 75 72 9b d2 bc 67-f2 fa 5b 75 80 a6 31 d8 .xur...g..[u..1. 
0060 - 71 15 85 7f 55 4d dc fb-b0 b5 33 db 6d 36 8c c6 q...UM....3.m6.. 
0070 - e8 f9 54 7a 29 69 87 2c-dd f3 c5 cf 26 55 6f 6e ..Tz)i.,....&Uon 
0080 - 45 73 7a 1d e4 b3 be b2-92 3f 0b ed c4 1c a5 24 Esz......?.....$ 
0090 - 3c f0 ca a5          <... 

Start Time: 1354063165 
Timeout : 300 (sec) 
Verify return code: 0 (ok)

但是連接到facebook沒有：

openssl s_client -connect graph.facebook.com:443 -debug -state -msg -CAfile /etc/ssl/certs/ca-certificates.crt -cipher SRP-AES-256-CBC- SHA

CONNECTED(00000003) 
SSL_connect:before/connect initialization 
write to 0xddd2c0 [0xddd340] (64 bytes => 64 (0x40)) 
0000 - 16 03 01 00 3b 01 00 00-37 03 02 50 b5 5d 75 42 ....;...7..P.]uB 
0010 - c2 78 55 49 b5 2e de 4f-00 a6 a8 d5 cf 10 92 44 .xUI...O.......D 
0020 - 28 62 34 d6 61 5e 88 c3-68 8b 96 00 00 04 c0 20 (b4.a^..h...... 
0030 - 00 ff 02 01 00 00 09 00-23 00 00 00 0f 00 01 01 ........#....... 
>>> TLS 1.1 [length 003b] 
    01 00 00 37 03 02 50 b5 5d 75 42 c2 78 55 49 b5 
    2e de 4f 00 a6 a8 d5 cf 10 92 44 28 62 34 d6 61 
    5e 88 c3 68 8b 96 00 00 04 c0 20 00 ff 02 01 00 
    00 09 00 23 00 00 00 0f 00 01 01 
SSL_connect:unknown state 
read from 0xddd2c0 [0xde28a0] (7 bytes => 7 (0x7)) 
0000 - 15 03 02 00 02 02 28        ......(
SSL3 alert read:fatal:handshake failure 
<<< TLS 1.1 [length 0002] 
    02 28 
SSL_connect:error in unknown state 
140581179446944:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:724: 
--- 
no peer certificate available 
--- 
No client certificate CA names sent 
--- 
SSL handshake has read 7 bytes and written 64 bytes 
--- 
New, (NONE), Cipher is (NONE) 
Secure Renegotiation IS NOT supported 
Compression: NONE 
Expansion: NONE

The facebook連接在客戶端發送其hello緩衝區之後掛起，並且從不接收服務器hello響應，或者如果傳入可識別的密碼，則返回錯誤代碼。這同時發生在-tls1和-ssl3上。我已經嘗試了所有我能想到的openssl參數。

容易緩存showpkg OpenSSL的

... 
Provides: 
1.0.1-4ubuntu5.5 - 
1.0.1-4ubuntu5.3 - 
1.0.1-4ubuntu3 -

我也想盡參數我能想到的捲曲，但沒有成功，因爲它使用OpenSSL的引擎蓋下。

我擔心Ubuntu無法建立安全連接（我意識到這是令人震驚的陳述）。經過兩個堅持不懈的對抗這個問題，我基本上正在祈禱有人知道一個解決方法。我正在考慮降級到OpenSSL 1.0.0，或者使用libcurl4-dev和gnutls-dev來代替。這兩種解決方案在我的口中留下了一種爛味道。預先感謝您提供的任何幫助。

P.S.所有這些工作都是爲了讓我的服務器可以與外部https REST API進行交互。我認爲這是今天任何網絡服務器的基本要求，沒有任何藉口。

更新：這是我的輸出沒有傳遞密碼。如果我通過不要緊-CAfile或也不：

的OpenSSL的s_client.First -connect graph.facebook.com:443 -debug -state -msg -CAfile /etc/ssl/certs/ca-certificates.crt

CONNECTED(00000003) 
SSL_connect:before/connect initialization 
write to 0x14ed1a0 [0x1515bf0] (226 bytes => 226 (0xE2)) 
0000 - 16 03 01 00 dd 01 00 00-d9 03 02 50 b6 39 78 6a ...........P.9xj 
0010 - 24 95 8e dc 62 19 37 4b-ab 77 b8 66 cd 48 ba a2 $...b.7K.w.f.H.. 
0020 - a1 2a f8 1d f8 c9 5d fb-9d db 84 00 00 66 c0 14 .*....]......f.. 
0030 - c0 0a c0 22 c0 21 00 39-00 38 00 88 00 87 c0 0f ...".!.9.8...... 
0040 - c0 05 00 35 00 84 c0 12-c0 08 c0 1c c0 1b 00 16 ...5............ 
0050 - 00 13 c0 0d c0 03 00 0a-c0 13 c0 09 c0 1f c0 1e ................ 
0060 - 00 33 00 32 00 9a 00 99-00 45 00 44 c0 0e c0 04 .3.2.....E.D.... 
0070 - 00 2f 00 96 00 41 c0 11-c0 07 c0 0c c0 02 00 05 ./...A.......... 
0080 - 00 04 00 15 00 12 00 09-00 14 00 11 00 08 00 06 ................ 
0090 - 00 03 00 ff 02 01 00 00-49 00 0b 00 04 03 00 01 ........I....... 
00a0 - 02 00 0a 00 34 00 32 00-0e 00 0d 00 19 00 0b 00 ....4.2......... 
00b0 - 0c 00 18 00 09 00 0a 00-16 00 17 00 08 00 06 00 ................ 
00c0 - 07 00 14 00 15 00 04 00-05 00 12 00 13 00 01 00 ................ 
00d0 - 02 00 03 00 0f 00 10 00-11 00 23 00 00 00 0f 00 ..........#..... 
00e0 - 01 01            .. 
>>> TLS 1.1 [length 00dd] 
    01 00 00 d9 03 02 50 b6 39 78 6a 24 95 8e dc 62 
    19 37 4b ab 77 b8 66 cd 48 ba a2 a1 2a f8 1d f8 
    c9 5d fb 9d db 84 00 00 66 c0 14 c0 0a c0 22 c0 
    21 00 39 00 38 00 88 00 87 c0 0f c0 05 00 35 00 
    84 c0 12 c0 08 c0 1c c0 1b 00 16 00 13 c0 0d c0 
    03 00 0a c0 13 c0 09 c0 1f c0 1e 00 33 00 32 00 
    9a 00 99 00 45 00 44 c0 0e c0 04 00 2f 00 96 00 
    41 c0 11 c0 07 c0 0c c0 02 00 05 00 04 00 15 00 
    12 00 09 00 14 00 11 00 08 00 06 00 03 00 ff 02 
    01 00 00 49 00 0b 00 04 03 00 01 02 00 0a 00 34 
    00 32 00 0e 00 0d 00 19 00 0b 00 0c 00 18 00 09 
    00 0a 00 16 00 17 00 08 00 06 00 07 00 14 00 15 
    00 04 00 05 00 12 00 13 00 01 00 02 00 03 00 0f 
    00 10 00 11 00 23 00 00 00 0f 00 01 01 
SSL_connect:unknown state

來源

2012-11-28 Zack Morris

爲什麼'-cipher SRP-AES-256-CBC-SHA'？ – Marek

我正在嘗試不同的密碼只是爲了得到任何迴應。如果沒有密碼，它會在客戶端發送你的請求後掛起，我從來沒有收到任何字節。 –

適用於我：http://pastebin.com/MXk7NPC5 –

爲什麼在連接graph.facebook.com時通過-cipher SRP-AES-256-CBC-SHA？ Facebook當然不支持SRP：http://srp.stanford.edu/。

如果你不通過它，它會工作嗎？

另外，你能給出你得到的IP地址嗎？在69.171.229.17中，我可以重現確切的ClientHello（以nonce爲模，以RC4-SHA爲惟一的密碼保存SCSV），並且我獲得了成功的握手。

最後，你有沒有試過通過SSH隧道到別的地方？可惜的是，在Chrome中部署TLS功能時，我們一再發現可破壞TLS連接的網絡硬件。（雖然我不能想到-ssl3不會修復它的情況，除非硬件正在主動嘗試審查連接。）

來源

2012-11-28 01:29:49

對你的職業生涯來說不是一個糟糕的開始。 :-) – ceejayoz

如果我通過graph.facebook.com或IP地址，它並不重要，它仍然掛起，但這是我看到：ping graph.facebook.com PING api.facebook.com（69.171.234.22） 56（84）字節的數據。來自api-read-slb-10-08-prn1.facebook.com（69.171.234.22）的64個字節：icmp_req = 1 ttl = 242 time = 30.2 ms –

另外，我同意你的觀點，即網絡硬件可能是問題，它可能與1500以下的MTU有關。但是，如果是這樣的話，這是openssl的一個缺陷，因爲（恕我直言）安全應該發生在流級而不是鏈路級，因爲無法知道數據包是如何路由的在野外。所以5分鐘後我就出來了，所以我不得不再添加一條評論。 –

將我的Ubuntu盒子上的MTU從1500設置爲1496（由於我們其中一個防火牆被設置得太低）讓我接收來自服務器的響應，而無需重啓（一定要首先調用ifconfig和寫下你原來的MTU應該是1500）：

sudo ifconfig eth0 mtu 1496

我發現我的MTU通過ping連續更大的緩衝區（爲UDP標頭添加28個字節）：

對於1472 + 28 = 1500失敗：

ping -s 1472 facebook.com 
PING facebook.com (66.220.158.16) 1472(1500) bytes of data. 
...

Works爲1468 + 28 = 1496：

ping -s 1468 facebook.com 
PING facebook.com (69.171.229.16) 1468(1496) bytes of data. 
1476 bytes from www-slb-ecmp-06-prn1.facebook.com (69.171.229.16): icmp_req=1 ttl=242 time=30.0 ms 
...

隨着1496我現在可以捲曲到facebook.com：

curl -v https://facebook.com 
* About to connect() to facebook.com port 443 (#0) 
* Trying 66.220.152.16... connected 
* successfully set certificate verify locations: 
* CAfile: none 
    CApath: /etc/ssl/certs 
* SSLv3, TLS handshake, Client hello (1): 
* SSLv3, TLS handshake, Server hello (2): 
* SSLv3, TLS handshake, CERT (11): 
* SSLv3, TLS handshake, Server finished (14): 
* SSLv3, TLS handshake, Client key exchange (16): 
* SSLv3, TLS change cipher, Client hello (1): 
* SSLv3, TLS handshake, Finished (20): 
* SSLv3, TLS change cipher, Client hello (1): 
* SSLv3, TLS handshake, Finished (20): 
* SSL connection using RC4-SHA 
* Server certificate: 
*  subject: C=US; ST=California; L=Palo Alto; O=Facebook, Inc.; CN=www.facebook.com 
*  start date: 2012-06-21 00:00:00 GMT 
*  expire date: 2013-12-31 23:59:59 GMT 
*  subjectAltName: facebook.com matched 
*  issuer: O=VeriSign Trust Network; OU=VeriSign, Inc.; OU=VeriSign International Server CA - Class 3; OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign 
*  SSL certificate verify ok. 
> GET/HTTP/1.1 
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3 
> Host: facebook.com 
> Accept: */* 
> 
< HTTP/1.1 301 Moved Permanently 
< Location: https://www.facebook.com/ 
< Content-Type: text/html; charset=utf-8 
< X-FB-Debug: 3vAg1O5OG9hB/EWC+gk1Kl3WLJRGmlQDaEodirWb+i0= 
< Date: Wed, 28 Nov 2012 19:52:25 GMT 
< Connection: keep-alive 
< Content-Length: 0 
< 
* Connection #0 to host facebook.com left intact 
* Closing connection #0 
* SSLv3, TLS alert, Client hello (1):

我個人認爲，應該MTU絕對有與用戶在流級別使用TCP看到的內容無關，所以我希望OpenSSL人員解決這個問題。我也希望有人會發明一個automagic錯誤提交程序來處理深度廣泛且時間很短的錯誤。

來源

2012-11-28 19:57:40

這解決了運行在vmware player 12.0.0 build-2985596（openssl package version 1.0.1f-1ubuntu2.15）上的Ubuntu 14.04.3 LTS的問題。在我的情況下，MTU降至1488。 – Ultraspider

在未連接到特定主機的debian服務器上有類似的問題，將MTU設置爲1450，問題已解決 – KauriNZ

Ubuntu中的OpenSSL 1.0.1握手解決方法？

回答

相關問題