2010-01-29 149 views
18

JSSE handshake_failure我讀了related question了,但它似乎並沒有在我看到一個失敗的同一個地方失敗。公共HTTPS網站

我想一個很簡單的操作:

public static void main(String [] argv) { 
    try { 
     URL u = new URL("https://membership.usairways.com/Login.aspx"); 
     Object o = u.getContent(); 
    } catch (MalformedURLException e) { 
     e.printStackTrace(); 
    } catch (IOException e) { 
     e.printStackTrace(); 
    } 
} 

但運行,當我得到一個handshake_failure與Java 6中,兩個我的Mac和Windows機器。

其他保持具有與該證書有問題沒有被發現,但調試日誌(-Djavax.net.debug=ssl:handshake)顯示了證書被發現就好了:

 
keyStore is : 
keyStore type is : jks 
keyStore provider is : 
init keystore 
init keymanager of type SunX509 
trustStore is: C:\Program Files (x86)\Java\jre6\lib\security\cacerts 
trustStore type is : jks 
trustStore provider is : 
init truststore 
adding as trusted cert: 
    Subject: CN=SwissSign Platinum CA - G2, O=SwissSign AG, C=CH 
    Issuer: CN=SwissSign Platinum CA - G2, O=SwissSign AG, C=CH 
    Algorithm: RSA; Serial number: 0x4eb200670c035d4f 
    Valid from Wed Oct 25 04:36:00 EDT 2006 until Sat Oct 25 04:36:00 EDT 2036 

(repeat above for a large number of certs, notably the next one here) 

adding as trusted cert: 
    Subject: EMAILADDRESS=premium-se[email protected], CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA 
    Issuer: [email protected], CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA 
    Algorithm: RSA; Serial number: 0x1 
    Valid from Wed Jul 31 20:00:00 EDT 1996 until Thu Dec 31 18:59:59 EST 2020 



trigger seeding of SecureRandom 
done seeding SecureRandom 
%% No cached client session 
*** ClientHello, TLSv1 
RandomCookie: GMT: 1264732935 bytes = { 200, 133, 119, 81, 212, 158, 149, 118, 153, 199, 116, 71, 201, 115, 67, 238, 141, 69, 2, 4, 158, 99, 39, 55, 242, 1, 155, 226 } 
Session ID: {} 
Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA] 
Compression Methods: { 0 } 
*** 
main, WRITE: TLSv1 Handshake, length = 73 
main, WRITE: SSLv2 client hello message, length = 98 
main, READ: SSLv3 Handshake, length = 74 
*** ServerHello, SSLv3 
RandomCookie: GMT: -1723164650 bytes = { 122, 187, 153, 122, 194, 216, 4, 86, 68, 106, 92, 83, 166, 22, 156, 103, 30, 93, 5, 89, 138, 108, 191, 101, 41, 38, 201, 7 } 
Session ID: {64, 200, 23, 188, 201, 247, 125, 29, 43, 132, 204, 32, 58, 18, 4, 215, 3, 228, 127, 3, 0, 13, 41, 240, 200, 79, 208, 166, 79, 178, 249, 123} 
Cipher Suite: SSL_RSA_WITH_RC4_128_MD5 
Compression Method: 0 
*** 
%% Created: [Session-1, SSL_RSA_WITH_RC4_128_MD5] 
** SSL_RSA_WITH_RC4_128_MD5 
main, READ: SSLv3 Handshake, length = 1712 
*** Certificate chain 
chain [0] = [ 
[ 
    Version: V3 
    Subject: CN=*.usairways.com, OU=csmusairwayweb, O=US Airways, L=Phoenix, ST=Arizona, C=US 
    Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5 

    Key: Sun RSA public key, 1024 bits 
    modulus: 117128872477092149134303805811049298494872749082923376652184544938174228731267664522970480129390452967053230586478159419504897327346652351403474804997804422528612377227107853983665176692187458180185822497353170111743696439530149540148901069359332724759471171438095948620900093160986648342991891132153788789693 
    public exponent: 65537 
    Validity: [From: Wed Apr 30 08:12:47 EDT 2008, 
       To: Fri Apr 30 08:12:47 EDT 2010] 
    Issuer: [email protected], CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA 
    SerialNumber: [ 645f032d 08d4bd17 40df6c90 666e6bf3] 

Certificate Extensions: 4 
[1]: ObjectId: 2.5.29.31 Criticality=false 
CRLDistributionPoints [ 
    [DistributionPoint: 
    [URIName: http://crl.thawte.com/ThawtePremiumServerCA.crl] 
]] 

[2]: ObjectId: 2.5.29.37 Criticality=false 
ExtendedKeyUsages [ 
    serverAuth 
    clientAuth 
] 

[3]: ObjectId: 2.5.29.19 Criticality=true 
BasicConstraints:[ 
    CA:false 
    PathLen: undefined 
] 

[4]: ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false 
AuthorityInfoAccess [ 
    [accessMethod: 1.3.6.1.5.5.7.48.1 
    accessLocation: URIName: http://ocsp.thawte.com] 
] 

] 
    Algorithm: [SHA1withRSA] 
    Signature: 
0000: 4A 2B 42 50 88 64 26 7E CA 06 8C B3 CA 88 B4 8D J+BP.d&......... 
0010: 20 5A 11 F6 1F 9E 00 16 22 46 6F D9 18 8E CE 08 Z......"Fo..... 
0020: 37 33 95 F9 08 2F 80 2D 26 73 C0 2A 54 2B 41 74 73.../.-&s.*T+At 
0030: 2F 7F BC 17 9C 85 E3 71 E0 D7 1D CE 76 86 DD 53 /......q....v..S 
0040: 2A 99 4E E7 92 27 F5 B5 2A A3 3C 9C D3 97 87 B9 *.N..'..*.%.....2q.. 
0070: 86 5E ED 50 27 A6 0D A6 23 F9 BB CB A6 07 14 42 .^.P'...#......B 

] 
*** 
Found trusted certificate: 
[ 
[ 
    Version: V3 
    Subject: [email protected], CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA 
    Signature Algorithm: MD5withRSA, OID = 1.2.840.113549.1.1.4 

    Key: Sun RSA public key, 1024 bits 
    modulus: 147615723393259181416635428961329342020669051439139433844527551020558419419302186744111967954084722208863267607710475139716371688682959340524636682374402009636778742019638875797953488482650734868036331360260559337468576998663423718393870107693392913633351064416793992445974512528326405756434384337574662315063 
    public exponent: 65537 
    Validity: [From: Wed Jul 31 20:00:00 EDT 1996, 
       To: Thu Dec 31 18:59:59 EST 2020] 
    Issuer: [email protected], CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA 
    SerialNumber: [ 01] 

Certificate Extensions: 1 
[1]: ObjectId: 2.5.29.19 Criticality=true 
BasicConstraints:[ 
    CA:true 
    PathLen:2147483647 
] 

] 
    Algorithm: [MD5withRSA] 
    Signature: 
0000: 26 48 2C 16 C2 58 FA E8 16 74 0C AA AA 5F 54 3F &H,..X...t..._T? 
0010: F2 D7 C9 78 60 5E 5E 6E 37 63 22 77 36 7E B2 17 ...x`^^n7c"w6... 
0020: C4 34 B9 F5 08 85 FC C9 01 38 FF 4D BE F2 16 42 .4.......8.M...B 
0030: 43 E7 BB 5A 46 FB C1 C6 11 1F F1 4A B0 28 46 C9 C..ZF......J.(F. 
0040: C3 C4 42 7D BC FA AB 59 6E D5 B7 51 88 11 E3 A4 ..B....Yn..Q.... 
0050: 85 19 6B 82 4C A4 0C 12 AD E9 A4 AE 3F F1 C3 49 ..k.L.......?..I 
0060: 65 9A 8C C5 C8 3E 25 B7 94 99 BB 92 32 71 07 F0 e....>%.....2q.. 
0070: 86 5E ED 50 27 A6 0D A6 23 F9 BB CB A6 07 14 42 .^.P'...#......B 

] 
main, READ: SSLv3 Handshake, length = 4 
*** ServerHelloDone 
*** ClientKeyExchange, RSA PreMasterSecret, SSLv3 
main, WRITE: SSLv3 Handshake, length = 132 
SESSION KEYGEN: 
PreMaster Secret: 
0000: 03 00 90 43 CA FE 69 A1 9B C1 D2 2A B2 52 B5 F7 ...C..i....*.R.. 
0010: 8F D7 6E 89 CB 9D B1 8F C0 C1 EE 54 D8 70 4A F2 ..n........T.pJ. 
0020: B6 FB D2 F2 1C BC FD 7A 2C AD 75 60 C0 5F 3B 15 .......z,.u`._;. 
CONNECTION KEYGEN: 
Client Nonce: 
0000: 4B 62 4B 07 C8 85 77 51 D4 9E 95 76 99 C7 74 47 KbK...wQ...v..tG 
0010: C9 73 43 EE 8D 45 02 04 9E 63 27 37 F2 01 9B E2 .sC..E...c'7.... 
Server Nonce: 
0000: 99 4B 98 16 7A BB 99 7A C2 D8 04 56 44 6A 5C 53 .K..z..z...VDj\S 
0010: A6 16 9C 67 1E 5D 05 59 8A 6C BF 65 29 26 C9 07 ...g.].Y.l.e)&.. 
Master Secret: 
0000: 65 CA 12 63 80 48 D8 4A 33 63 A3 93 6F FB F8 5A e..c.H.J3c..o..Z 
0010: 87 7D 2E C4 19 3D 0E 2E 66 D4 0A 28 B8 27 76 79 .....=..f..(.'vy 
0020: F9 C8 53 67 0D 87 CB 47 29 9E 3E 37 44 7D 19 11 ..Sg...G).>7D... 
Client MAC write Secret: 
0000: 26 03 49 9F 35 73 6B B4 2E 22 BF EC 57 84 F1 55 &.I.5sk.."..W..U 
Server MAC write Secret: 
0000: 3F D0 4C 7F AD 9B 16 CD 9F 1E 81 DD 0E B9 88 CF ?.L............. 
Client write key: 
0000: 55 C0 0D 36 BA 82 88 26 7B CE 16 BC B0 96 5D 9F U..6...&......]. 
Server write key: 
0000: 73 B1 C3 EF E5 1F E7 B4 B9 90 BA B9 EC D7 13 70 s..............p 
... no IV used for this cipher 
main, WRITE: SSLv3 Change Cipher Spec, length = 1 
*** Finished 
verify_data: { 36, 108, 19, 115, 108, 210, 76, 3, 226, 30, 160, 20, 81, 59, 1, 35, 71, 57, 221, 18, 4, 164, 97, 253, 166, 69, 253, 104, 207, 70, 44, 39, 0, 231, 237, 172 } 
*** 
main, WRITE: SSLv3 Handshake, length = 56 
main, READ: SSLv3 Alert, length = 2 
main, RECV SSLv3 ALERT: fatal, handshake_failure 
main, called closeSocket() 
main, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure 
javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure 
    at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown Source) 
    at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown Source) 
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(Unknown Source) 
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source) 
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source) 
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source) 
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source) 
    at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source) 
    at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source) 
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source) 
    at java.net.URLConnection.getContent(Unknown Source) 
    at sun.net.www.protocol.https.HttpsURLConnectionImpl.getContent(Unknown Source) 
    at java.net.URL.getContent(Unknown Source) 
    at h.Hacks.main(Hacks.java:11) 



編輯2010/1/31:

考慮使用Wireshark的數據包,客戶端問候消息是火狐3.5和Java 1.6之間略有不同。

爪哇1.6發送的SSLv2 hello消息,但版本被設置爲TLS 1.0(0x0301)

火狐3.5發送的SSLv2 hello消息,但版本被設置爲SSLv3.0(0x0300)

服務器似乎以同樣的方式響應兩者。首先服務器Hello報文,然後與服務器證書和組合包「服務器問候完成」

的Java和Firefox的反應不同: 的Java發送三個SSL記錄三個包:客戶端密鑰交換,然後更改密碼規範,然後加密的握手消息

Firefox將這三個SSL記錄作爲一個數據包發送。

在這一點上,對Java,服務器會發送一個致命的警報表明握手失敗,而Firefox的獲取成功完成握手過程的響應。

我最好在這一點上的猜測是,無論是使用TLSv1的從Java最初的請求是令人困惑的事情,或者單獨的包有點難以理解服務器。 任何想法我怎麼能測試這些理論?



編輯2010/2/1: 讀一個相關的問題,我看到「OpenSSL的」命令行工具可以診斷某些問題。運行 openssl s_client -connect membership.usairways.com:443顯示發送TLSv1請求正常工作。因此,Java與服務器交互的方式更爲微妙。

回答

15

還有就是你的設置:

System.setProperty("https.protocols", "SSLv3"); 

你是正確的 - 這是SSL版本引起該問題。 Here是某種解釋。

恭喜你這個精心研究的問題!

+0

哇!非常感謝,這就是訣竅。 – TheDon 2010-02-15 19:39:49

+0

我沒忘記。 :)一旦我接受了答案,我就不能改變主意,所以我確保它做到了我想要的。 – TheDon 2010-02-15 20:51:04

+0

好:)順便說一句,我測試了它,它返回了頁面的整個內容。 – Bozho 2010-02-15 20:54:18

1

我與FF 3.6連接到網站嗅了嗅使用Wireshark的連接。事實上,第一次SSL連接嘗試發送一個TLS1.0客戶端hello,並且服務器響應握手故障,然後FF3.6立即使用兼容SSLv2的hello重試。所有這些都對用戶透明,所以你不會注意到最初的失敗。嘗試將系統屬性https.protocols設置爲SSLv2Hello。請注意,JSSE不支持SSL v2,這只是初始客戶端hello的格式。

編輯:

好吧,沒關係,我看到JSSE默認使用的SSLv2客戶端問候。我不知道爲什麼第一次連接嘗試失敗。也許你只需要連續嘗試兩次。

+0

我嘗試用try/catch包裝現有的u.getContent(),然後在catch之後放入另一個u.getContent()。這隻會導致兩個堆棧跟蹤。還是你的意思是'連續嘗試兩次'的其他意思? – TheDon 2010-01-29 04:19:52

+0

我的意思基本上是這樣,但爲第二次嘗試創建一個新的URL對象。 – 2010-01-30 00:10:14