1

I understand the SSL handshake flow, but I'm facing a logic problem with an abbreviated SSL handshake.

Use case: The user is authenticated on system for common ways, such as passwords. But for some actions the user can be requested to present a digital certificate to confirm your identity. That's has legal implications for some countries like Brazil (ref. http://www.iti.gov.br/icp-brasil), use digital certificate is necessary to confirm that this person (or company) is in fact the person holding that national identity number.

After selecting the client certificate using SSL handshake is necessary to validate it against application to know that its reliable and match with any system user using something like National identification number, that could be on Common Name or another Certificate field (eg. https://pt.wikipedia.org/wiki/E-CPF for Brazilian example).

But, if some reason, the user selects a wrong certificate. It's a valid certificate but, don't match with the user, an error message is sent but I must allow another certificate selection process (ssl handshake) for this user. Some user could have more than one certificate on your PC.

enter image description here

In this scenario, to select another certificate, the user must close the browser and open again, but it gives a negative user experience and I want to improve it.

The solution is very clear, I need to perform a full handshake for every request, so It allows user to select another one.

But how to do that?

The most relevant e question that I found was Avoiding SSL handshake for each call It's exactly opposite of I want to do.

These two definitions are crucial to the general understanding:

  • The full handshake is what a client and server do when they don't know each other (they have not talked previously, or that was long ago). In the full handshake, certificates are sent, and asymmetric cryptography (RSA, Diffie-Hellman...) occurs.
  • The abbreviated handshake is what a client and server remember each other; moreaccurately, they remember the algorithms and keys that they established in a previous full handshake, and agree to reuse them (technically, they reuse the "master secret" and derive from it fresh encryption keys for this connection).

I posted at my web-server official forum (https://redmine.lighttpd.net/boards/2/topics/7284?r=7286) but their marked my question as invalid **saying that is a client side problem. But is it? ** I can free any information from the browser, close tab, and disable keep alive, but a second handshake doesn't open certificate prompt until I close the browser.

My image bellow is using the Chrome for example and it doesn't have an option "remember my decision", Firefox has. The same happens with Edge, Opera, Edge etc. **Is it a standard? **

I guess, that it can be controlled by server side, requesting a new full SSL Handshake. I made some interventions to try solve it by myself, but was unsuccessful

  • at client-side:

    • Clear all data, even history.
    • Open in another sub-domain cookieless

  • at server-side:

    • Send "Connection: close" header
    • Disable keep-alive

Close the browser is the only effective for a new SSL Handshake, but it will promote a bad user experience.

It should have a way to renegotiate this authentication.

LeonanCarvalho
  • 204
  • 3
  • 13
  • 1
    I don't have a good solution, but do you really want a full handshake on *every* request? Meaning, it continues asking for the certificate even if was valid a second ago? – Mike Caron Apr 17 '17 at 17:26
  • Also, if you reject the connection with the bad certificate, that should clue the browser in that it's incorrect. I don't know how feasible that is in your case, but it's the "correct" solution – Mike Caron Apr 17 '17 at 17:27
  • Yes, that's the point. I must request a full handshake on every request. This request will be run over a sub-domain or a specific URI. The purpose is just get a information on certificate. – LeonanCarvalho Apr 17 '17 at 17:34
  • The purpose is just identify the user, but not grant secure connection client-to-server. The handshake occurs at the server layer, there is no way (unless I develop the web server) to check this certificate information before it completes the handshake. – LeonanCarvalho Apr 17 '17 at 17:39
  • 1
    Could you just ask the user to upload the certificate directly? Although, you'd have to ask for the private portion in order to positively identify them... Yeah, I have nothing. The best I can suggest is a lot of messaging to help the user pick the correct certificate! – Mike Caron Apr 17 '17 at 17:48
  • @MikeCaron Upload the cert file is insecure, we don't wanna store this information. Only that we need is the Common Name and Serial the handshake works fine, taking this boring part of the negotiation. About the help, this is the our main approach, a lot of help and warnings about that. And a orientation about close and re-open the browse to pick another one. – LeonanCarvalho Apr 17 '17 at 18:32

0 Answers0