RE: SNI Support

Does safari over secure channel work, as you expect?

Here is one IDEA, knowing how Microsoft though about its obligations to make an export-enforcing platform. It just a hunch, given the information about re-negotiation and some known gotchas.

Not all secure channel lib consumers get the same behavior, concerning formerly export-controlled renegotiation practices (2 handshakes on the same TCP connection). Only certain export-controlled client (e.g. IE) got to 'apply' certain SSL capabilities expressed through double handshaking (remembering that Netscape servers and IIS server used double handshaking differently). Just because you link to the dll didn’t mean the engine would expose the export-controlled features to the DLL consuming app. Put another way, not all apps got to leverage the ability of a special server certs, minted by particular CAs, to signal through double handshaking that the CHANNEL would not then  reveal lots of the derived keying material from the KDF to the passive wire interceptor.


I found it fascinating that different Mozilla use different ssl/crypto libs. Its unlikely, from a security analysis perspective, they all behave the same - even if they appear functionally similar to the user.

-----Original Message-----
From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org] On Behalf Of Andrei Sambra
Sent: Sunday, May 01, 2011 3:06 PM
To: WebID XG
Subject: Re: SNI Support

Bergi and I have been playing with Apache over the weekend, trying to identify possible issues related to browsers not validating CAs. So far, we haven't concluded much, other than Safari seems not to support secure renegotiation (Safari: "client does not support secure renegotiation"), while Firefox 4.0 and Chrome 11 do support it. 

It could also be that under Ubuntu (my test client OS), Firefox uses libgnutls26, instead of openssl. Bergi tested with Safari under Win7 and it passed verification on both his endpoint and mine. Under Windows, Safari uses the windows ssl libs (Secure Channel).

The full trace containing tests for Safari / Firefox / Chrome can be found here: http://webid.fcns.eu/apache.log.new.txt

If any of you is strong in the art of Apache-foo, please let us know if you can manage to spot something we might have missed.

Andrei 


On Fri, 2011-04-29 at 21:39 +0200, Andrei Sambra wrote:
> Forgot to add the other options of my SSL setup:
> 
> SSLVerifyClient optional_no_ca
> SSLVerifyDepth 1
> SSLOptions +ExportCertData
> 
> Other than these, I have the server certificate file and it's secret 
> key.
> 
> The server runs on a dedicated IP address, using a wildcard 
> certificate
> (*.fcns.eu) issued by AlphaSSL.
> 
> Andrei
> 
> On Fri, 2011-04-29 at 21:00 +0200, Andrei Sambra wrote:
> > Hello,
> > 
> > I've come to the conclusion that using "SSLVerifyClient optional_no_ca"
> > is mutually exclusive to having a valid CA bundle file. Some issuers 
> > (AlphaSSL in my case) require that websites must also provide the CA 
> > bundle file (the certification chain).
> > 
> > If a CA bundle file is provided and the option "SSLVerifyClient 
> > optional_no_ca" is used (in order to authenticate WebID users by 
> > requiring their browser certificate), then the authentication does 
> > not happen anymore (the server no longer asks for a certificate).
> > 
> > If the CA bundle file is not used, the authentication takes place 
> > just fine. However, some browsers will not be able to verify the 
> > server certificate's issuer -> the same behavior as using 
> > self-signed server certificates; which makes one wonder why pay for 
> > a signed certificate in the first place.
> > 
> > I'm open to suggestions at this point...
> > 
> > Andrei
> > 
> > On Fri, 2011-04-29 at 09:39 +0200, Andrei Sambra wrote:
> > > Being a wildcard certificate, it has to use the same CN: 
> > > *.fcns.eu. I cannot add other subdomains, since it would require 
> > > issuing new certificates -> me paying for them. :-)
> > > 
> > > Another possibility would be to switch to a different hosting 
> > > provider / CA.
> > > 
> > > What's weird is that after a clean install of Ubuntu (w/ FF 4.0) 
> > > on a lab machine, I had the same warning regarding the validity of 
> > > the server certificate. Weird...
> > > 
> > > I'll try to document all these issues on the wiki somewhere, so we 
> > > have a starting base.
> > > 
> > > Andrei
> > > 
> > > On Fri, 2011-04-29 at 00:56 +0200, bergi wrote:
> > > > Andrei, I would expect that your server doesn't use SNI, because 
> > > > your certificate uses the common name *.fcns.eu. I think the IE 
> > > > had/has problems with wildcard common names. Perhaps also safari 
> > > > doesn't like these certificates. You are already using the 
> > > > alternative name for fcns.eu. You could try to add your other subdomains to avoid problems.
> > > > 
> > > 
> > > 
> > > 
> > 
> > 
> > 
> 
> 
>

Received on Sunday, 1 May 2011 22:45:31 UTC