I have found a workaround -> It seems to be a mix of a bug in the JVM
and Jetty's choice of JDK implementation.
Anyway, switching from using the *SelectChannelConnector (Non-blocking
IO) to *SocketConnector (Blocking IO) lets it work.
With SSLSelectChannelConnector's implementation, OpenSSL's (and ICS's)
TLS handshake failed whilst waiting for a ServerHello (which never
came -> but Jetty didn't spit out any useful error).
With SSLSocketConnector's implementation, OpenSSL's (and ICS's) TLS
handshake still fails, but this time the server actually responds (see
below transcript), allowing the client to know about this issue and
revert to SSL3 (or other options) for the few devices which don't seem
to correctly work with this (NB: Chrome, Firefox etc. still have no
issue using TLS to connect).
The old OpenSSL log looked like:
╰─$ openssl s_client -connect wave.eezysys.co.uk:443 -debug
-tlsextdebug -msg
[130] [21:36:10]
CONNECTED(00000003)
write to 0x15b4a90 [0x15b4b10] (210 bytes => 210 (0xD2))
0000 - 16 03 01 00 cd 01 00 00-c9 03 01 4f 2e f6 9a 8f ...........O....
0010 - a4 95 1c 40 6f be c3 23-dc f4 a5 11 7b ec 6e b1 ...@o..#....{.n.
0020 - d7 5d b3 65 6f 8c 2d 64-59 ce 11 00 00 5c c0 14 .].eo.-dY....\..
0030 - c0 0a 00 39 00 38 00 88-00 87 c0 0f c0 05 00 35 ...9.8.........5
0040 - 00 84 c0 12 c0 08 00 16-00 13 c0 0d c0 03 00 0a ................
0050 - c0 13 c0 09 00 33 00 32-00 9a 00 99 00 45 00 44 .....3.2.....E.D
0060 - c0 0e c0 04 00 2f 00 96-00 41 00 07 c0 11 c0 07 ...../...A......
0070 - c0 0c c0 02 00 05 00 04-00 15 00 12 00 09 00 14 ................
0080 - 00 11 00 08 00 06 00 03-00 ff 01 00 00 44 00 0b .............D..
0090 - 00 04 03 00 01 02 00 0a-00 34 00 32 00 01 00 02 .........4.2....
00a0 - 00 03 00 04 00 05 00 06-00 07 00 08 00 09 00 0a ................
00b0 - 00 0b 00 0c 00 0d 00 0e-00 0f 00 10 00 11 00 12 ................
00c0 - 00 13 00 14 00 15 00 16-00 17 00 18 00 19 00 23 ...............#
00d2 - <SPACES/NULS>
>>> TLS 1.0 Handshake [length 00cd], ClientHello
01 00 00 c9 03 01 4f 2e f6 9a 8f a4 95 1c 40 6f
be c3 23 dc f4 a5 11 7b ec 6e b1 d7 5d b3 65 6f
8c 2d 64 59 ce 11 00 00 5c c0 14 c0 0a 00 39 00
38 00 88 00 87 c0 0f c0 05 00 35 00 84 c0 12 c0
08 00 16 00 13 c0 0d c0 03 00 0a c0 13 c0 09 00
33 00 32 00 9a 00 99 00 45 00 44 c0 0e c0 04 00
2f 00 96 00 41 00 07 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 01 00 00 44 00 0b 00 04 03 00 01
02 00 0a 00 34 00 32 00 01 00 02 00 03 00 04 00
05 00 06 00 07 00 08 00 09 00 0a 00 0b 00 0c 00
0d 00 0e 00 0f 00 10 00 11 00 12 00 13 00 14 00
15 00 16 00 17 00 18 00 19 00 23 00 00
^C
The new OpenSSL log looks like:
╰─$ openssl s_client -connect 192.168.1.128:9898 -msg
[1] [21:53:08]
CONNECTED(00000003)
>>> TLS 1.0 Handshake [length 00cd], ClientHello
01 00 00 c9 03 01 4f 2e fa 5a a6 f3 13 7a fc fb
e7 75 13 4a 00 f1 44 31 7c 26 ae c5 5d 70 e1 23
95 02 ee be fd f0 00 00 5c c0 14 c0 0a 00 39 00
38 00 88 00 87 c0 0f c0 05 00 35 00 84 c0 12 c0
08 00 16 00 13 c0 0d c0 03 00 0a c0 13 c0 09 00
33 00 32 00 9a 00 99 00 45 00 44 c0 0e c0 04 00
2f 00 96 00 41 00 07 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 01 00 00 44 00 0b 00 04 03 00 01
02 00 0a 00 34 00 32 00 01 00 02 00 03 00 04 00
05 00 06 00 07 00 08 00 09 00 0a 00 0b 00 0c 00
0d 00 0e 00 0f 00 10 00 11 00 12 00 13 00 14 00
15 00 16 00 17 00 18 00 19 00 23 00 00
<<< TLS 1.0 Alert [length 0002], fatal internal_error
02 50
140573611484840:error:14077438:SSL
routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal
error:s23_clnt.c:658:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 210 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
There are of course issues with moving to BIO -> namely that there is
now a higher overhead since we need to keep spawning new threads each
time, so the max client's the server can support is expected to fall a
bit[1] but I think this is ok, for increasing the number of devices
that we can support.
I shall update my review patch for this change as well.
[1]: http://iobound.com/2008/11/comet-nio/
On 1 February 2012 22:43, Ali Lown <[email protected]> wrote:
> Updated the patch for review to the one I am using.
>
> I haven't yet been able to solve the ICS/OpenSSL issue much to my irritation.
> Ideas on this are welcome since I am not a security expert (or have
> ever used JSSE before...)
>
> On 31 January 2012 10:56, Thomas Leonard <[email protected]>
> wrote:
>> Would it be worth applying the patch anyway, with a note in the config that
>> this doesn't work with all clients (and is disabled by default)? That would
>> allow wider testing.
>>
>>
>>
>> On 2012-01-29 23:01, Ali Lown wrote:
>>>
>>> OpenSSL's s_client is also unable to connect when asked to use the TLS
>>> cipher suites (but can do SSL3 ones fine).
>>> This is despite the web browsers (Chrome, Firefox etc.) all connecting
>>> via TLS 1.0
>>>
>>> It is looking like a bug/limitation in Jetty's SSL engine to me now,
>>> rather than an issue with ICS's browser.
>>>
>>> Still looking into this issue before sending any further patches/updates.
>>>
>>> On 29 January 2012 15:08, Ali Lown<[email protected]> wrote:
>>>>
>>>> Found another issue with the implementation:
>>>> For some reason Android ICS's Browser has a 'time out' when loading
>>>> the page, yet Gingerbread, Froyo etc. are fine.
>>>>
>>>> They must have changed something to do with the SSL handshake the
>>>> device performs when running ICS.
>>>>
>>>> Other devices, eg. iPhone have no issue with the handshake...
>>>>
>>>> Looking into this now.
>>>>
>>>> On 26 January 2012 20:33, Ali Lown<[email protected]> wrote:
>>>>>
>>>>> Oops, just discovered that my patch broke the bots (due to them all
>>>>> having hard-coded 'http' URLs in the code). The fact it took me a week
>>>>> despite running it on my server, suggests this code isn't ready yet.
>>>>>
>>>>> I will submit a new patch to fix this in a few days time, once I have
>>>>> had a chance to check for any other bugs it may have introduced.
>>>>>
>>>>> On 22 January 2012 22:59, Ali Lown<[email protected]> wrote:
>>>>>>
>>>>>> Sent a review request for most of the code.
>>>>>> To get socket.io to work correctly though I had to edit socket.io.js
>>>>>> in the third_party/runtime/socketio/socketio-core-0.1-SNAPSHOT.jar
>>>>>> (attached here for your reference).
>>>>>>
>>>>>> As for the issue of privileged ports, I have chosen to run WIAB on a
>>>>>> non-privileged, and with the help of an iptables REDIRECT, can make it
>>>>>> appear to be running on 443.
>>>>>>
>>>>>> Works for me. :)
>>>>>>
>>>>>> On 18 January 2012 15:12, Vicente J. Ruiz Jurado<[email protected]>
>>>>>> wrote:
>>>>>>>
>>>>>>> El 18/01/12 00:20, Ali Lown escribió:
>>>>>>>>
>>>>>>>> I had a go at setting it up and yes this method of adjusting jetty
>>>>>>>> seems to work fine.
>>>>>>>>
>>>>>>>> Over the next couple of days I will have a go at writing a patch so
>>>>>>>> that we can choose between ssl (and normal) listeners, keystore
>>>>>>>> location and password all from the configuration file.
>>>>>>>
>>>>>>>
>>>>>>> Just to say: Great job guys!
>>>>>>>
>>
>> --
>> Dr Thomas Leonard
>> IT Innovation Centre
>> Gamma House, Enterprise Road,
>> Southampton SO16 7NS, UK
>>
>>
>> tel: +44 23 8059 8866
>>
>> mailto:[email protected]
>> http://www.it-innovation.soton.ac.uk/
