A crypto library aimed at auditability

Posted Jan 13, 2014 4:27 UTC (Mon) by Cyberax (✭ supporter ✭, #52523)
In reply to: A crypto library aimed at auditability by luto
Parent article: A crypto library aimed at auditability

>And then what? It's obvious how to encrypt a file to email to the server using NaCl, but what am I supposed to do to encrypt a session?

Yeah, it's more complicated. Especially if you care about PFS and stuff. But not impossible, I did this for my protocol.

It's about 200 lines of Python code (though I use AES-CTR because it's so much faster when accelerated using AES-NI instead of DJB's ciphers), I'll refactor it into a separate library and publish.

>If you have a concrete answer, do you know how to prove that your answer meets any sensible security requirement? The point of NaCl is to make this kind of stuff easy, but I think it falls down for sessions.
Yes, for now. Though it's fairly easy to fix.

>Sure it is. TLS tells you exactly what to do, once you've chosen a TLS version, cipher suite, kex algo, etc., and once you've figured out how to use one of the many awful TLS libraries
My main problem with TLS is its complexity and the complete opaqueness of its tools. For example, I still search Google for the exact command line when I need to generate a CSR or make a self-signed certificate.

to post comments

A crypto library aimed at auditability

Posted Jan 13, 2014 6:55 UTC (Mon) by luto (subscriber, #39314) [Link] (25 responses)

It's about 200 lines of Python code (though I use AES-CTR because it's so much faster when accelerated using AES-NI instead of DJB's ciphers), I'll refactor it into a separate library and publish.

Now I'm curious: how did you make a secure session layer out of AES-CTR as a primitive in Python that has anywhere near the performance of DJB's cipher suite? AES-CTR isn't authenticated...

A crypto library aimed at auditability

Posted Jan 13, 2014 6:58 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (24 responses)

Oh, I'm using OpenSSL's implementation (through a ctypes wrapper) which is wickedly fast.

I'm using DJB's curve (a pure Python version) to negotiate the session key, and a simple protocol to establish the connection (authenticated exchange of nonces).

A crypto library aimed at auditability

Posted Jan 13, 2014 17:28 UTC (Mon) by luto (subscriber, #39314) [Link] (23 responses)

I'll take as given that your session setup is completely perfect. How are you convincing AES-CTR to prevent a MITM from changing the data as it goes by?

NaCl's crypto_secretbox uses Poly1305 for this. It's cheap, but it's not free.

A crypto library aimed at auditability

Posted Jan 13, 2014 17:42 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (22 responses)

For my session setup, I can show that it's not affected by any external data, not related to the key material (including nonces). Other than that, I'm pretty sure it should be good enough if underlying ciphers are sound.

Another my gripe with TLS/SSL is that it has too many useless features. For example, TLS supports re-keying and cipher changes in the middle of a session. Yet there are no legitimate reasons for this, it's simply a cargo-cult security which only increases attack surface (and in fact there were vulnerabilities in TLS re-negotitation).

> I'll take as given that your session setup is completely perfect. How are you convincing AES-CTR to prevent a MITM from changing the data as it goes by?
By using HMAC-SHA1 to authenticate messages (hash-before-encryption strategy), which is pretty fast.

> NaCl's crypto_secretbox uses Poly1305 for this. It's cheap, but it's not free.
HMAC-SHA1 is OK for my purposes. I don't think that it can be feasibly broken for my scenario (authentication of short-lived network messages).

AES-CTR (I might switch to AES-GCM) takes care of replay attacks, so there's no need for per-message nonces.

A crypto library aimed at auditability

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

> Another my gripe with TLS/SSL is that it has too many useless features. For example, TLS supports re-keying and cipher changes in the middle of a session. Yet there are no legitimate reasons for this,

Actually, I have run into reasons for this.

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.

A crypto library aimed at auditability

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

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.

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.

A crypto library aimed at auditability

Posted Jan 13, 2014 19:54 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

> This requires the renegotiation that you claim there is no legitimate reason for.
No it doesn't. Simply break the session and start a new one if you must, it can even be done right now by using another domain for requests that require client certificates.

And besides, client certificate authorization should be in a wholly different layer. SSL/TLS should be used to establish a secure server-to-client session, and if a client wishes to authenticate itself it should do it using appropriate higher-level protocols.

And it's not a coincidence that certificate-based authorization is used only in cases where major user inconvenience is not a problem, like banking websites. The only another case where I've seen it used is on StartSSL's site.

A crypto library aimed at auditability

Posted Jan 20, 2014 16:08 UTC (Mon) by ThomasBellman (guest, #67902) [Link]

> And it's not a coincidence that certificate-based authorization
> is used only in cases where major user inconvenience is not a
> problem, like banking websites. The only another case where I've
> seen it used is on StartSSL's site.

Client certificates are used extensively in the grid computing community (Worldwide LHC Computing Grid, European Grid Infrastructure, and so on). Not just for submitting jobs, but also for authenticating to various web sites, like wikis, ticketing systems, monitoring systems, and so on. And many institutions that only work in the grid a little bit on the side (like where I work, with only 3 out of 30 people do grid stuff), use client certificate authentication for almost all our non-grid websites as well.

It is somewhat painful to get your client certificate and install it in your browser, in particular for people who are not computer experts, but once you have it, it is definitely very *convenient* to be automatically logged in to lots of sites without having to look up a username and password for each site.