Remy van Elst <relst@...> writes: > > Lukas Tribus schreef op 09/01/14 00:08: > > Hi, > > > > > >> $ openssl s_client -state -quiet -connect xx.xx.xx.xx:443 > >> > >> SSL_connect:before/connect initialization > >> SSL_connect:SSLv2/v3 write client hello A > >> SSL_connect:SSLv3 read server hello A > >> depth=4 /C=NL/O=xxx/CN=xxx > >> verify error:num=19:self signed certificate in certificate chain > >> verify return:0 > >> SSL_connect:SSLv3 read server certificate A > >> SSL_connect:SSLv3 read server key exchange A > >> SSL_connect:SSLv3 read server done A > >> SSL_connect:SSLv3 write client key exchange A > >> SSL_connect:SSLv3 write change cipher spec A > >> SSL_connect:SSLv3 write finished A > >> SSL_connect:SSLv3 flush data > >> SSL_connect:SSLv3 read finished A > >> GET /admin/ HTTP/1.0 > >> > >> SSL_connect:SSL renegotiate ciphers > >> SSL_connect:SSLv3 write client hello A > >> SSL_connect:SSLv3 read server hello A > >> depth=4 /C=NL/O=xxx/CN=xxx > >> verify error:num=19:self signed certificate in certificate chain > >> verify return:0 > >> SSL_connect:SSLv3 read server certificate A > >> SSL_connect:SSLv3 read server key exchange A > >> SSL_connect:SSLv3 read server certificate request A > >> SSL_connect:SSLv3 read server done A > >> SSL_connect:SSLv3 write client certificate A > >> SSL_connect:SSLv3 write client key exchange A > >> SSL_connect:SSLv3 write change cipher spec A > >> SSL_connect:SSLv3 write finished A > >> SSL_connect:SSLv3 flush data > >> SSL3 alert read:fatal:handshake failure > > Ok, its clear what Apache is doing. After matching the /admin/ path, > > Apache triggers a SSL renegotiation and within that renegotiation requests > > the client certificate from the browser. > > > > Because this all happens with a renegotiation, this is probably valid > > behavior from a SSL/TLS perspective. > > > > It is still a layering violation imho, because we trigger layer 5 > > renegotiation by matching a layer 7 event and I would rather avoid that. > > > > > > > >> In the testing phase (now), some clients have issues with the app > >> (because they have a certificate in their browser). On Apache/F5 they > >> are not asked for a certificate in using the app, only admins are. > > I understand this now; your actual customers are seeing this, if they > > have at least 1 client certificate in the browser, even though they > > don't use, care and know about the /admin/ path, which you are only > > using internally. > > > > I see why this sucks. > > > > > > > >> If it is not possible to do this with haproxy (because it is invalid > >> according to the spec) then I'll probably suggest they move the admin > >> interface out of the user-facing part of the app. > > Yes, I suggest you do this. You will need to do this with a second bind > > statement, which means either moving it to a different port or to a > > different IP address. > > > > What would make sense in HAproxy however is the possibility to set the > > verify command based on SNI values and I think there are some very valid > > use cases that could benefit from it (SNI based virtual hosting with > > different client-cert settings or like in your case a dedicated admin > > interface). > > > > We already have a snifilter for crt-list [1], extending "verify" with a > > snifilter is probably doable. > > > > > > > > Regards, > > > > Lukas > > > > > > [1] http://cbonte.github.io/haproxy-dconv/configuration- 1.5.html#5.1-crt-list > Thank you again for the great explanation both. It is indeed just the > user facing part, functional wise the client certificate just works. I > think I like the setup with two apps better than what we have now, > should also make it easier to firewall the admin part better. > > Cheers, > > > Attachment (smime.p7s): application/pkcs7-signature, 3722 bytes
Hi, There are some valid use cases for requiring client certificate for a specific URI and not asking for it otherwise. In example Estonian ID card (I'm sure there are others) - a smart card is inserted into reader and it's person's certificate can be read from there (after pin validation). This is a common secure 2-factor authentication mechanism here. Basic use case goes like this: * user is on site (doesn't matter if on http or https) * some action requires user to be securely identified * user is redirected to an URI that requires client certificate * user enters hes PIN and certificate is sent to server, server validates it and considers the user securely authorized/authenticated * user continues on https In use cases like this, it is essential that we don't ask (or even accept) client certificate on any other pages, just on the authentication page creating a subdomain and load-balancing it separately, just for this one page seems a huge overkill (the authentication page doesn't need to do anything, we'd be fine if LB could forward the cert in HTTP headers, but its imperative that we only require/accept the cert on one URI) IIS 8.0 seems to do the same trick as apache (you can set SSL client certificate requirements per-page in IIS as well), SSL dump: openssl s_client -state -quiet -connect xxx.xxx.xxx.xxx:443 SSL_connect:before/connect initialization SSL_connect:SSLv2/v3 write client hello A SSL_connect:SSLv3 read server hello A depth=2 C = US, O = XX, OU = XX, OU = XX, CN = XX verify error:num=20:unable to get local issuer certificate SSL_connect:SSLv3 read server certificate A SSL_connect:SSLv3 read server done A SSL_connect:SSLv3 write client key exchange A SSL_connect:SSLv3 write change cipher spec A SSL_connect:SSLv3 write finished A SSL_connect:SSLv3 flush data SSL_connect:SSLv3 read finished A GET /Id.aspx SSL_connect:SSL renegotiate ciphers SSL_connect:SSLv3 write client hello A SSL_connect:SSLv3 read server hello A depth=2 C = US, O = XX, OU = XX, OU = XX, CN = XX verify error:num=20:unable to get local issuer certificate SSL_connect:SSLv3 read server certificate A SSL_connect:SSLv3 read server certificate request A SSL_connect:SSLv3 read server done A SSL_connect:SSLv3 write client certificate A SSL_connect:SSLv3 write client key exchange A SSL_connect:SSLv3 write change cipher spec A SSL_connect:SSLv3 write finished A SSL_connect:SSLv3 flush data SSL_connect:SSLv3 read finished A
