I just ran a quick test using Chrome 9.0.597.19 beta I ran it from the command line with the --disable-ssl-false-start flag
The results were unchanged from previous tests where the handshake never completes. I may get WireShark installed to see if I can figure out any more details. Google Chrome9.0.597.19 (Official Build 68937) betaWebKit534.13V82.5.9.1User AgentMozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.13 (KHTML, like Gecko) Chrome/9.0.597.19 Safari/534.13Command Linechrome -–disable-ssl-false-start --flag-switches-begin --flag-switches-end On Mon, Dec 27, 2010 at 5:37 PM, Emmanuel Lecharny <[email protected]>wrote: > On 12/28/10 12:04 AM, [email protected] wrote: > >> I'm having a strange problem with the SslFilter in that all tested >> browsers >> except Google Chrome can connect to the filter. This is the latest >> release >> of Chrome running on either Mac or Windows. >> >> I stress that this is a CA issued certificate, so there are no self-signed >> trust issues. Also, Chrome can SSL handshake with this the certificate >> when >> connecting to IIS, so it is something specific to my Mina/SslFilter setup >> >> I believe that there is some handshake problem, but I don't know how to >> troubleshoot what it might be, or why only Chrome fails of all the >> browsers. >> I sure would appreciate any advice >> > Could it be related to the fact that Chrome has a very specific feature in > the latest version, called 'False-start', implemented in order to speed-up > SSL connection . > > > http://www.belshe.com/2010/12/05/chrome-speeding-up-ssl-with-ssl-falsestart/ > > Would be interesting to get a wireshark trace to see if this is the > problem, and to see what could be the impact on MINA server code, if we were > to support this feature. > > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com > >
