为什么 iOS 5 无法连接到运行 JDK 1.6 的服务器,但无法连接到 JDK 1.5

2022-09-02 04:52:45

我们有一个Java套接字服务器监听SSSocket(端口443)和一个与之连接的iOS应用程序。在 iOS 5.1 上运行时,当我们将服务器的 Java 版本从 JDK 1.5 升级到 1.6(或 1.7)时,应用程序停止工作。在iOS 6上运行时,该应用程序可以很好地连接到JDK 5和6。

iOS 应用程序报告错误:。在Java方面,我们得到了.-9809 = errSSLCryptojavax.net.ssl.SSLException: Received fatal alert: close_notify

在 Java 服务器端,我们启用了所有可用的密码套件。在客户端,我们已经测试了启用几个不同的套件,尽管我们尚未完成涉及每个套件单独启用的测试。现在,当我们使用时,它是失败的,尽管它已经与其他人一起失败了,我们开始认为它不是套件。TLS_DH_anon_WITH_AES_128_CBC_SHA

下面是调试输出。它一路走到,然后不久就失败了:ServerHelloDone

Is secure renegotiation: false
[Raw read]: length = 5
0000: 16 03 03 00 41                                     ....A
[Raw read]: length = 65
0000: 01 00 00 3D 03 03 50 83   1E 0B 56 19 25 65 C8 F2  ...=..P...V.%e..
0010: AF 02 AD 48 FE E2 92 CF   B8 D7 A6 A3 EA C5 FF 5D  ...H...........]
0020: 74 0F 1B C1 99 18 00 00   08 00 FF 00 34 00 1B 00  t...........4...
0030: 18 01 00 00 0C 00 0D 00   08 00 06 05 01 04 01 02  ................
0040: 01                                                 .
URT-, READ: Unknown-3.3 Handshake, length = 65
*** ClientHello, Unknown-3.3
RandomCookie:  GMT: 1333992971 bytes = { 86, 25, 37, 101, 200, 242, 175, 2, 173, 72, 254, 226, 146, 207, 184, 215, 166, 163, 234, 197, 255, 93, 116, 15, 27, 193, 153, 24 }
Session ID:  {}
Cipher Suites: [TLS_EMPTY_RENEGOTIATION_INFO_SCSV, TLS_DH_anon_WITH_AES_128_CBC_SHA, SSL_DH_anon_WITH_3DES_EDE_CBC_SHA, SSL_DH_anon_WITH_RC4_128_MD5]
Compression Methods:  { 0 }
Unsupported extension signature_algorithms, data: 00:06:05:01:04:01:02:01
***
[read] MD5 and SHA1 hashes:  len = 65
0000: 01 00 00 3D 03 03 50 83   1E 0B 56 19 25 65 C8 F2  ...=..P...V.%e..
0010: AF 02 AD 48 FE E2 92 CF   B8 D7 A6 A3 EA C5 FF 5D  ...H...........]
0020: 74 0F 1B C1 99 18 00 00   08 00 FF 00 34 00 1B 00  t...........4...
0030: 18 01 00 00 0C 00 0D 00   08 00 06 05 01 04 01 02  ................
0040: 01                                                 .
%% Created:  [Session-1, TLS_DH_anon_WITH_AES_128_CBC_SHA]
*** ServerHello, TLSv1
RandomCookie:  GMT: 1333992972 bytes = { 100, 3, 56, 153, 7, 2, 251, 64, 41, 32, 66, 240, 227, 181, 55, 190, 2, 237, 146, 0, 73, 119, 70, 0, 160, 9, 28, 207 }
Session ID:  {80, 131, 30, 12, 241, 73, 52, 38, 46, 41, 237, 226, 199, 246, 156, 45, 3, 247, 182, 43, 223, 8, 49, 169, 188, 63, 160, 41, 102, 199, 50, 190}
Cipher Suite: TLS_DH_anon_WITH_AES_128_CBC_SHA
Compression Method: 0
Extension renegotiation_info, renegotiated_connection: <empty>
***
Cipher suite:  TLS_DH_anon_WITH_AES_128_CBC_SHA
*** Diffie-Hellman ServerKeyExchange
DH Modulus:  { 233, 230, 66, 89, 157, 53, 95, 55, 201, 127, 253, 53, 103, 18, 11, 142, 37, 201, 205, 67, 233, 39, 179, 169, 103, 15, 190, 197, 216, 144, 20, 25, 34, 210, 195, 179, 173, 36, 128, 9, 55, 153, 134, 157, 30, 132, 106, 171, 73, 250, 176, 173, 38, 210, 206, 106, 34, 33, 157, 71, 11, 206, 125, 119, 125, 74, 33, 251, 233, 194, 112, 181, 127, 96, 112, 2, 243, 206, 248, 57, 54, 148, 207, 69, 238, 54, 136, 193, 26, 140, 86, 171, 18, 122, 61, 175 }
DH Base:  { 48, 71, 10, 213, 160, 5, 251, 20, 206, 45, 157, 205, 135, 227, 139, 199, 209, 177, 197, 250, 203, 174, 203, 233, 95, 25, 10, 167, 163, 29, 35, 196, 219, 188, 190, 6, 23, 69, 68, 64, 26, 91, 44, 2, 9, 101, 216, 194, 189, 33, 113, 211, 102, 132, 69, 119, 31, 116, 186, 8, 77, 32, 41, 216, 60, 28, 21, 133, 71, 243, 169, 241, 162, 113, 91, 226, 61, 81, 174, 77, 62, 90, 31, 106, 112, 100, 243, 22, 147, 58, 52, 109, 63, 82, 146, 82 }
Server DH Public Key:  { 8, 60, 59, 13, 224, 110, 32, 168, 116, 139, 246, 146, 15, 12, 216, 107, 82, 182, 140, 80, 193, 237, 159, 189, 87, 34, 18, 197, 181, 252, 26, 27, 94, 160, 188, 162, 30, 29, 165, 165, 68, 152, 11, 204, 251, 187, 14, 233, 239, 103, 134, 168, 181, 173, 206, 151, 197, 128, 65, 239, 233, 191, 29, 196, 93, 80, 217, 55, 81, 240, 101, 31, 119, 98, 188, 211, 52, 146, 168, 127, 127, 66, 63, 111, 198, 134, 70, 213, 31, 162, 146, 25, 178, 79, 56, 116 }
Anonymous
*** ServerHelloDone
[write] MD5 and SHA1 hashes:  len = 383
0000: 02 00 00 4D 03 01 50 83   1E 0C 64 03 38 99 07 02  ...M..P...d.8...
0010: FB 40 29 20 42 F0 E3 B5   37 BE 02 ED 92 00 49 77  .@) B...7.....Iw
0020: 46 00 A0 09 1C CF 20 50   83 1E 0C F1 49 34 26 2E  F..... P....I4&.
0030: 29 ED E2 C7 F6 9C 2D 03   F7 B6 2B DF 08 31 A9 BC  ).....-...+..1..
0040: 3F A0 29 66 C7 32 BE 00   34 00 00 05 FF 01 00 01  ?.)f.2..4.......
0050: 00 0C 00 01 26 00 60 E9   E6 42 59 9D 35 5F 37 C9  ....&.`..BY.5_7.
0060: 7F FD 35 67 12 0B 8E 25   C9 CD 43 E9 27 B3 A9 67  ..5g...%..C.'..g
0070: 0F BE C5 D8 90 14 19 22   D2 C3 B3 AD 24 80 09 37  ......."....$..7
0080: 99 86 9D 1E 84 6A AB 49   FA B0 AD 26 D2 CE 6A 22  .....j.I...&..j"
0090: 21 9D 47 0B CE 7D 77 7D   4A 21 FB E9 C2 70 B5 7F  !.G...w.J!...p..
00A0: 60 70 02 F3 CE F8 39 36   94 CF 45 EE 36 88 C1 1A  `p....96..E.6...
00B0: 8C 56 AB 12 7A 3D AF 00   60 30 47 0A D5 A0 05 FB  .V..z=..`0G.....
00C0: 14 CE 2D 9D CD 87 E3 8B   C7 D1 B1 C5 FA CB AE CB  ..-.............
00D0: E9 5F 19 0A A7 A3 1D 23   C4 DB BC BE 06 17 45 44  ._.....#......ED
00E0: 40 1A 5B 2C 02 09 65 D8   C2 BD 21 71 D3 66 84 45  @.[,..e...!q.f.E
00F0: 77 1F 74 BA 08 4D 20 29   D8 3C 1C 15 85 47 F3 A9  w.t..M ).<...G..
0100: F1 A2 71 5B E2 3D 51 AE   4D 3E 5A 1F 6A 70 64 F3  ..q[.=Q.M>Z.jpd.
0110: 16 93 3A 34 6D 3F 52 92   52 00 60 08 3C 3B 0D E0  ..:4m?R.R.`.<;..
0120: 6E 20 A8 74 8B F6 92 0F   0C D8 6B 52 B6 8C 50 C1  n .t......kR..P.
0130: ED 9F BD 57 22 12 C5 B5   FC 1A 1B 5E A0 BC A2 1E  ...W"......^....
0140: 1D A5 A5 44 98 0B CC FB   BB 0E E9 EF 67 86 A8 B5  ...D........g...
0150: AD CE 97 C5 80 41 EF E9   BF 1D C4 5D 50 D9 37 51  .....A.....]P.7Q
0160: F0 65 1F 77 62 BC D3 34   92 A8 7F 7F 42 3F 6F C6  .e.wb..4....B?o.
0170: 86 46 D5 1F A2 92 19 B2   4F 38 74 0E 00 00 00     .F......O8t....
URT-, WRITE: TLSv1 Handshake, length = 383
[Raw write]: length = 388
0000: 16 03 01 01 7F 02 00 00   4D 03 01 50 83 1E 0C 64  ........M..P...d
0010: 03 38 99 07 02 FB 40 29   20 42 F0 E3 B5 37 BE 02  .8....@) B...7..
0020: ED 92 00 49 77 46 00 A0   09 1C CF 20 50 83 1E 0C  ...IwF..... P...
0030: F1 49 34 26 2E 29 ED E2   C7 F6 9C 2D 03 F7 B6 2B  .I4&.).....-...+
0040: DF 08 31 A9 BC 3F A0 29   66 C7 32 BE 00 34 00 00  ..1..?.)f.2..4..
0050: 05 FF 01 00 01 00 0C 00   01 26 00 60 E9 E6 42 59  .........&.`..BY
0060: 9D 35 5F 37 C9 7F FD 35   67 12 0B 8E 25 C9 CD 43  .5_7...5g...%..C
0070: E9 27 B3 A9 67 0F BE C5   D8 90 14 19 22 D2 C3 B3  .'..g......."...
0080: AD 24 80 09 37 99 86 9D   1E 84 6A AB 49 FA B0 AD  .$..7.....j.I...
0090: 26 D2 CE 6A 22 21 9D 47   0B CE 7D 77 7D 4A 21 FB  &..j"!.G...w.J!.
00A0: E9 C2 70 B5 7F 60 70 02   F3 CE F8 39 36 94 CF 45  ..p..`p....96..E
00B0: EE 36 88 C1 1A 8C 56 AB   12 7A 3D AF 00 60 30 47  .6....V..z=..`0G
00C0: 0A D5 A0 05 FB 14 CE 2D   9D CD 87 E3 8B C7 D1 B1  .......-........
00D0: C5 FA CB AE CB E9 5F 19   0A A7 A3 1D 23 C4 DB BC  ......_.....#...
00E0: BE 06 17 45 44 40 1A 5B   2C 02 09 65 D8 C2 BD 21  ...ED@.[,..e...!
00F0: 71 D3 66 84 45 77 1F 74   BA 08 4D 20 29 D8 3C 1C  q.f.Ew.t..M ).<.
0100: 15 85 47 F3 A9 F1 A2 71   5B E2 3D 51 AE 4D 3E 5A  ..G....q[.=Q.M>Z
0110: 1F 6A 70 64 F3 16 93 3A   34 6D 3F 52 92 52 00 60  .jpd...:4m?R.R.`
0120: 08 3C 3B 0D E0 6E 20 A8   74 8B F6 92 0F 0C D8 6B  .<;..n .t......k
0130: 52 B6 8C 50 C1 ED 9F BD   57 22 12 C5 B5 FC 1A 1B  R..P....W"......
0140: 5E A0 BC A2 1E 1D A5 A5   44 98 0B CC FB BB 0E E9  ^.......D.......
0150: EF 67 86 A8 B5 AD CE 97   C5 80 41 EF E9 BF 1D C4  .g........A.....
0160: 5D 50 D9 37 51 F0 65 1F   77 62 BC D3 34 92 A8 7F  ]P.7Q.e.wb..4...
0170: 7F 42 3F 6F C6 86 46 D5   1F A2 92 19 B2 4F 38 74  .B?o..F......O8t
0180: 0E 00 00 00                                        ....
[Raw read]: length = 5
0000: 15 03 01 00 02                                     .....
[Raw read]: length = 2
0000: 02 00                                              ..
URT-, READ: TLSv1 Alert, length = 2
URT-, RECV TLSv1 ALERT:  fatal, close_notify
URT-, called closeSocket()
URT-, handling exception: javax.net.ssl.SSLException: Received fatal alert: close_notify

仅供参考,这适用于iOS 6.0


答案 1

您是否尝试过从 Java 服务器导出“新”自签名证书并导入到应用/操作系统的信任存储?


答案 2

如果应用程序与JDK5一起使用,我建议使用JDK6重复相同的测试并比较两个日志文件:然后应该清楚真正的差异在哪里。

检查调试日志时,服务器说客户端正在发送致命的close_notify消息,因此服务器会立即关闭连接,这是正确的服务器行为。

7.2.1. 关闭警报

客户端和服务器必须共享连接正在结束的知识,以避免截断攻击。任何一方都可以启动关闭消息的交换。

close_notify此消息通知收件人发件人不会在此连接上再发送任何邮件。请注意,从 TLS 1.1 开始,如果无法正确关闭连接,则不再需要不恢复会话。这是从 TLS 1.0 到符合广泛实施实践的更改。

任何一方都可以通过发送close_notify警报来启动关闭。关闭警报后收到的任何数据都将被忽略。除非已传输其他致命警报,否则每一方都需要在关闭连接的写入端之前发送close_notify警报。另一方必须以自己的close_notify警报进行响应,并立即关闭连接,丢弃任何挂起的写入。关闭的发起方不需要在关闭连接的读取端之前等待响应close_notify警报。

关于TLS_DH_anon_WITH_AES_128_CBC_SHA,请注意JDK6u29中有一个回归修复程序,该修复程序使用TLS_DH_anon_WITH_AES_128_CBC_SHA破坏了SSL连接。更多信息在这里:

http://www.oracle.com/technetwork/java/javase/documentation/overview-137139.html http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7103725