Why does iOS 5 fail to connect to a server running JDK 1.6, but not JDK 1.5

Question

We have a Java Socket Server listening on an SSLSocket (port 443) and an iOS application that connects with it. When running on iOS 5.1, the application stopped working when we upgraded the Java version of the server from JDK 1.5 to 1.6 (or 1.7). The app connects just fine to JDK 5 and 6 when running on iOS 6.

The iOS app is reporting an error: -9809 = errSSLCrypto. On the Java side, we get javax.net.ssl.SSLException: Received fatal alert: close_notify.

On the Java server side, we have enabled all the available cipher suites. On the client side we have tested enabling several different suites, although we have yet to complete a test involving each one individually enabled. Right now, it is failing when we use TLS_DH_anon_WITH_AES_128_CBC_SHA although it has failed with others and we are starting to think it's not the suite.

Here is the debug output. It makes it all the way to ServerHelloDone and then fails shortly thereafter:

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

FYI, this works in iOS 6.0

Lesleelesley

Are you allowed to use anonymous cipher suites in the Apple App publication mechanism? – Neuroticism

@Bruno, I think yes that is why its working on iOS5 - Java 5. But fails only when we upgrade the Java version to 6 on our Server. – Workbench

Not sure about the Java version issue, I'm just surprised that Apple would accept an app that uses anon ciphers, because as far as I understand, they refuse apps that disable certificate verification. Anon cipher suites are more or less the same. It would be interesting to see a trace when it works too. Have you tried to force other cipher suites (TLS_DH_anon_WITH_AES_128_CBC_SHA is selected here)? – Neuroticism

We have tried all the DH cipher suites because they don't require a certificate. We are now going to disable the DH ciphers and try the ones that do require a cert. – Lesleelesley

I'm just wondering if you'd be allowed anonymous cipher suites in the App Store. I would assume it would be rejected there, since it seems Apple would reject apps that ignore the certificate verification. – Neuroticism

(Following a comment posted in a deleted answer) Anonymous cipher suites and not verif certs are different things indeed, but the result is the same: you don't check the identity of the remote party and are therefore vulnerable to MITM attacks. Rejecting apps that allow any cert makes sense to avoid MITM attacks (and bad publicity). It would make sense to reject apps that use anonymous cipher suites for the same reason. Even without the threat of rejection, if you care about your app not being open to MITM attacks, don't use anon cipher suites. – Neuroticism

I don't know about IOS. I was thinking about a change to the default parameters on the Java side. The 'SSLv2Hello' handshake protocol formerly was enabled by default but is now disabled by default. This might not be your problem, though, as it was changed in Java7, not 6. oracle.com/technetwork/java/javase/compatibility-417013.html – Overpay

Answer 1

Have you tried exporting a "new" self signed certificate from the Java server and import to the trust store of your app/OS?

Publus

We tried this but the client appeared to reject the cert. I'm not sure if the cert we created correctly matched the hostname of the server it was on. I'm also not sure if this matters once you've imported the cert on the iPhone. – Lesleelesley

If device rejected the cert, there is something wrong with it.. Can you regen and try once more.. And I think it matters, for SSL connections server validation is mandatory and only for a valid cert in trust store, device will make a connection. – Publus

Answer 2

If the app works with JDK5, I suggest to repeat the same test with JDK6 and compare the two log files: it should then be clear where the real differences are.

Inspecting your debug log, the server is saying that the client is sending a fatal close_notify message, and because of this the server closes the connection immediately, and that is the right server behavior.

7.2.1. Closure Alerts

The client and the server must share knowledge that the connection is ending in order to avoid a truncation attack. Either party may initiate the exchange of closing messages.

close_notify This message notifies the recipient that the sender will not send any more messages on this connection. Note that as of TLS 1.1, failure to properly close a connection no longer requires that a session not be resumed. This is a change from TLS 1.0 to conform with widespread implementation practice.

Either party may initiate a close by sending a close_notify alert. Any data received after a closure alert is ignored. Unless some other fatal alert has been transmitted, each party is required to send a close_notify alert before closing the write side of the connection. The other party MUST respond with a close_notify alert of its own and close down the connection immediately, discarding any pending writes. It is not required for the initiator of the close to wait for the responding close_notify alert before closing the read side of the connection.

About TLS_DH_anon_WITH_AES_128_CBC_SHA, please note there was a REGRESSION fix in JDK6u29 that broke SSL connectivity using TLS_DH_anon_WITH_AES_128_CBC_SHA. More info here:

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

Kenney

Answer 3

May I suggest to use Apache or another HTTP(S) Server in front of your Java application Server? Just thinking into the future perhaps your application will not have Java serving directly all requests anyway (think about TLS security fixes, load balancing, failover etc). My two cents.

Concertmaster