A crypto library aimed at auditability

Posted Jan 13, 2014 19:03 UTC (Mon) by luto (subscriber, #39314)
In reply to: A crypto library aimed at auditability by dlang
Parent article: A crypto library aimed at auditability

someone may want to login to a website and have it secured via TLS, then at some point they want to go to a more secure portion of the website where you want to use a client cert for authentication. This requires the renegotiation that you claim there is no legitimate reason for.

It requires the ability to submit a proof that you possess the private key for a certificate. I don't know of any reason that it requires renegotiating session keys, other than the fact that the only way that TLS defined to send a client certificate mid-session is to renegotiate the whole thing.

to post comments

A crypto library aimed at auditability

Posted Jan 13, 2014 19:09 UTC (Mon) by dlang (guest, #313) [Link] (17 responses)

The way client certs work is that the client and server certs are validated at the same time by the PKI handshake.If you don't use an explicit client cert, your browser makes up one to use instead. When you decide you want to now use one, you need to do the negotiation again.

What you are suggestion as a proof of identity is possible, but it's not something any encryption spec currently supports.

Every encryption spec that authenticates the client as well as the server does this validation as part of the initial encryption handshake.

A crypto library aimed at auditability

Posted Jan 13, 2014 19:16 UTC (Mon) by luto (subscriber, #39314) [Link] (11 responses)

I swear I saw an encryption spec somewhere that allowed higher layers to ask for additional keying material after the session was established (i.e. session-key-derived bytes).

The intent was for one party to be able to sign a message (using any signature system they want!) that says "I am indeed a party to the session that has key-derived bytes XYZ". The other party verifies the signature and checks that XYZ is correct and now knows that the client is who it says it is.

This is nice because it's completely in-band (unlike TLS renegotiation, which has an awkward API). It's also simple and can't possibly reduce the security of the connection (unlike TLS renegotiation, which, in its initial version, allowed all kinds of attacks even if client certificates weren't involved).

A crypto library aimed at auditability

Posted Jan 13, 2014 19:38 UTC (Mon) by dlang (guest, #313) [Link] (10 responses)

I haven't seen a spec that did that, which doesn't mean that there isn't one out there.

But you need to realize, one big reason why SSL/TLS have been as successful as they are is that the higher level application doesn't really know about them. There is a bit more work needed at connection initialization time, and there are some more 'environment variables' that you may have an interest in, but other than that the application can completely ignore the fact that SSL/TLS are there.

and may applications do almost exactly that. It's how many things, including HTTP get 'secured', you just take an unmodified app/protocol and wrap it in SSL/TLS

A crypto library aimed at auditability

Posted Jan 13, 2014 19:39 UTC (Mon) by luto (subscriber, #39314) [Link] (9 responses)

Once you're talking about asking for a client certificate mid-connection, though, the application layer very much needs to know about it -- it has to know to ask for the certificate.

A crypto library aimed at auditability

Posted Jan 13, 2014 20:02 UTC (Mon) by dlang (guest, #313) [Link] (8 responses)

> Once you're talking about asking for a client certificate mid-connection, though, the application layer very much needs to know about it -- it has to know to ask for the certificate.

What happens with Apache is that you configure a directory to require a client cert. When someone tries to access that directory, the authentication check fails and triggers a renegotiation.

Yes, you could redirect them to a different domain, but that would require a different cert (and IP address with SSL), this may not be a big deal for a single site, but at my last job we have a couple thousand such sites, at that point doubling the number of certs and IP addresses needed is a big deal.

A crypto library aimed at auditability

Posted Jan 13, 2014 20:03 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

> Yes, you could redirect them to a different domain, but that would require a different cert (and IP address with SSL), this may not be a big deal for a single site, but at my last job we have a couple thousand such sites, at that point doubling the number of certs and IP addresses needed is a big deal.

Let me chime in and say that this is YET ANOTHER case of mixing network layers. SSL/TLS are just designed too badly.

A crypto library aimed at auditability

Posted Jan 13, 2014 20:06 UTC (Mon) by luto (subscriber, #39314) [Link]

I'm not sure that we're talking about the same thing. All I'm saying is that, for an application (e.g. Apache) to ask for a certificate mid-connection (e.g. when it sees GET /super_secret), it needs to know about the underlying crypto layer (so it can ask for that certificate).

It's true that, in TLS, this can be done without modifying HTTP, but I'm not sure that's a good thing. In any case, a different crypto layer could support the operation "ask for a client certificate" without renegotiating any session keys.

A crypto library aimed at auditability

Posted Jan 13, 2014 21:19 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (5 responses)

> and IP address with SSL

Maybe come April you could just start assuming SNI ;) .

A crypto library aimed at auditability

Posted Jan 13, 2014 21:32 UTC (Mon) by dlang (guest, #313) [Link] (4 responses)

that depends on if you need to support older browsers or not. That's a business decision, not a technical one.

A crypto library aimed at auditability

Posted Jan 13, 2014 22:56 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (3 responses)

It is a business decision, but its the SSL implementation in XP that doesn't support SNI, not the browser itself and it doesn't look like browsers can do much (I see reports of Chrome 24 not supporting SNI on XP).

A crypto library aimed at auditability

Posted Jan 16, 2014 9:30 UTC (Thu) by ssokolow (guest, #94568) [Link] (2 responses)

Browsers on XP will have TLS SNI if they bring along their own crypto libraries rather than using the OS-provided ones. (Which everyone except IE and Safari for Windows does apparently)

According to Wikipedia, Chrome uses Firefox's NSS libraries and SHOULD have working TLS SNI under XP but it's broken somehow.

A crypto library aimed at auditability

Posted Jan 16, 2014 13:52 UTC (Thu) by cortana (subscriber, #24596) [Link] (1 responses)

Chrome uses the Windows API for SSL on Windows.

A crypto library aimed at auditability

Posted Jan 16, 2014 13:57 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

It looks like there is also a registry value[1], but it defaults to 0. That's for crome-frame, not Chrome itself, but I imagine Chrome would have its own stack if chrome-frame does.

I also saw that Firefox 3 worked on XP, so it does look like it *can work there.

[1]https://groups.google.com/forum/m/#!topic/google-chrome-f...

A crypto library aimed at auditability

Posted Jan 13, 2014 20:02 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

> The way client certs work is that the client and server certs are validated at the same time by the PKI handshake.

Yet there's no NEED for this. Client only needs to authenticate the server (by its public key) and it's done both parties can assume that the communication channel is secure, in the sense that there can't be any MITMs.

However, the server side might want to make sure that the client is really whom it claims to be. That can be done in higher levels - in HTTP form-based authorization, for example. It should also be possible to do this by the exchange of signed nonces, except that there is no standard for this :(

A crypto library aimed at auditability

Posted Jan 13, 2014 20:10 UTC (Mon) by luto (subscriber, #39314) [Link] (3 responses)

I don't think your protocol works. I think you're saying:

Client connects to server and verifies server cert. All remaining communication goes over the resulting channel.

Server -> Client: server_nonce
Client -> Server: Sign(server_nonce)

This isn't secure without a lot of care -- an attacker could get the client to connect (knowingly) to the attacker, and then the attacker could ask the client to sign the real server's nonce. Game over.

This is why I think that a good protocol would provide nonces that are bound to the session key.

A crypto library aimed at auditability

Posted Jan 13, 2014 20:21 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

> I don't think your protocol works.
Well, it does.

> This isn't secure without a lot of care -- an attacker could get the client to connect (knowingly) to the attacker
Client MUST verify the server's public key (either by getting it in some secure fashion or by checking its certificate chain).

>and then the attacker could ask the client to sign the real server's nonce. Game over.
Sure, it's possible.

It can be easily fixed by signing server's public key hash along with the nonce. That is a layering violation, and it shouldn't be necessary if the underlying layers work as they are designed to.

A crypto library aimed at auditability

Posted Jan 13, 2014 20:33 UTC (Mon) by luto (subscriber, #39314) [Link] (1 responses)

It can be easily fixed by signing server's public key hash along with the nonce. That is a layering violation, and it shouldn't be necessary if the underlying layers work as they are designed to.

No, or at least not without great care. If the underlying layer guarantees that the client is talking to who it thinks it is, and the client signs a message saying "I'm XYZ", and the server receives a (validly signed) message saying "I'm XYZ", it does not follow that the client intended that message for the same server that's receiving it.

Remember, the attacker's server can violate the protocol and send a nonce that came from somewhere else, unless the underlying protocol provides some specific mechanism to prevent this, such as session-specific key material

A crypto library aimed at auditability

Posted Jan 13, 2014 20:43 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

>Remember, the attacker's server can violate the protocol and send a nonce that came from somewhere else, unless the underlying protocol provides some specific mechanism to prevent this, such as session-specific key material

Uhm, the server name is definitely going to be a part of the nonce. I haven't mentioned it, thinking that it's self-obvious.

Of course, the server authentication and name resolution becomes a critical part of the chain then. But I think it's a fair trade-off for avoiding layering violations.

And signing the server's public key used for session initialization also allows to avoid this attack as in TLS/SSL, at the cost of layering violation.