jsse handshake_failure 在公共 https 网站上

2022-09-02 22:06:29

我已经阅读了一个相关的问题,但它似乎并没有在我看到失败的同一个地方失败。

我正在尝试一个非常简单的操作:

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();
    }
}

但是当我在我的Mac和Windows机器上使用Java 6运行时,我得到了一个handshake_failure。

其他人一直遇到找不到证书的问题,但调试日志()显示证书被找到很好:-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-server@thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
  Issuer:  EMAILADDRESS=premium-server@thawte.com, 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: EMAILADDRESS=premium-server@thawte.com, 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: EMAILADDRESS=premium-server@thawte.com, 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: EMAILADDRESS=premium-server@thawte.com, 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)



编辑1/31/2010:

查看使用wireshark的数据包,Firefox 3.5和Java 1.6之间的客户端hello消息略有不同。

Java 1.6 发送 SSLv2 hello 消息,但版本设置为 TLS 1.0 (0x0301)

Firefox 3.5 发送 SSLv2 hello 消息,但版本设置为 SSLv3.0 (0x0300)

服务器似乎以相同的方式响应两者。首先是服务器 hello 数据包,然后是带有服务器证书和“服务器 hello done”的组合数据包

Java 和 Firefox 的响应不同:Java 将三条 SSL 记录作为三个数据包发送:客户端密钥交换,然后更改密码规范,然后加密握手消息

Firefox 将所有这三条 SSL 记录作为一个数据包发送。

此时,对于 Java,服务器会发送一个致命警报,指示握手失败,而 firefox 会获得一个成功完成握手过程的响应。

在这一点上,我最好的猜测是,要么是来自java的TLSv1的初始请求令人困惑,要么是单独的数据包以某种方式混淆了服务器。任何想法,我怎么能测试这两个理论?



编辑2/1/2010:阅读相关问题,我看到“openssl”命令行工具可以诊断某些问题。运行表明发送 TLSv1 请求工作正常。因此,Java与服务器交互的方式更加微妙。openssl s_client -connect membership.usairways.com:443

答案 1

有您的设置:

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

您是对的 - 这是导致问题的SSL版本。这里有一些解释。

恭喜你提出了一个很好且经过充分研究的问题!


答案 2

我使用FF 3.6连接到该网站,并嗅到了与Wireshark的连接。实际上,第一次SSL连接尝试发送TLS1.0客户端hello,服务器响应握手失败,然后FF3.6立即使用SSLv2兼容hello重试,成功。所有这些都对用户透明地发生,因此您不会注意到最初的失败。尝试将系统属性设置为 。请注意,JSSE 不支持 SSL v2,这只是初始客户端 hello 的格式。https.protocolsSSLv2Hello

编辑:

好吧,没关系,我看到JSSE默认使用SSLv2客户端hello。我不知道为什么第一次连接尝试失败。也许你只需要连续尝试两次。