Validate TLS certificates [$155 awarded] #89
Assignees
adam (Adam Wojcieszonek)
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: adam/znc#89
Reference in new issue
Block a user
What we need to check:
- The peer name (or alt), wild comparison, could be "*.example.com".
- If any certificate in the chain has expired.
- Ensure root certificate is trusted (the OS/distro usually packages a set of CA files to compare this against).
- Validate the certificate chain (ensure each certificate in the chain is signed correctly by the certificate above).
--- The **[$155 bounty](https://www.bountysource.com/issues/674-validate-tls-certificates?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** on this issue has been claimed at [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github).Validate for what? I bet openssl already makes sure that there are no malformed certificates involved :-P
The domain, date, the CA, etc?
Yes, OpenSSL can do those things, but you need to make sure you've asked for it.
What exactly do you mean with "those things"? I am pretty sure that, for example, OpenSSL cannot check if a given domain name matches the certificate's subject.
No idea if it verifies the date (= if the cert is yet/still valid), but it definitely checks the issuer chain.
What other properties of a cert would we need to check? How much ugly, ugly code would that take?
What we need to check:
SSL_get_verify_result()can be used, but I am not sure what this checks.I believe this is an important issue. Here's a PDF with an abundance of information on the topic: http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf
Some old code that I once wrote for something like this:
https://github.com/psychon/znc/commits/openssl-experiments
However, this is security-sensitive stuff and I have no clue about what exactly the rules for this kind of things are. In other words: I feel really unsure about this and have no clue if it is correct. (Also, I didn't look at the branch in years...)
Given that very few IRC servers have valid certificates, "trust on first use" in addition to the chain validation would be more useful...
User should be presented an option to allow cert, if the cert is invalid. User should explicitly allow this particular invalid cert. "trust on first use" is bad if you want security
Isn't that exactly what "trust on first use" usually means?
Hm, if it means that, ok... For me it sounded like "if we connect to the server for the first time, trust it anyway".
Good that I've mistaken.
Just for reference, here is how HexChat implements it: https://github.com/hexchat/hexchat/blob/master/src/common/server.c#L624 Though I don't see that they would validate the CN, too… :-)
grawity, DarthGandalf: Looking at how other programs handle invalid certificates, I'd say there could be two approaches:
In the mean time, https://www.stunnel.org/ can be used to establish a secure SSL connection from the bouncer to the IRC server (thanks to a friend of mine for recommending me this).
I added a bounty to this :)
I'd love for ZNC to verify that:
How should it be handled with different fingerprints?
Id guess some networks that have different servers run independently that are connected where they have a different cert for each server use different fingerprints? Maybe a list of trusted fingerprints?
Hmm, I'm not sure, a list of fingerprints sounds reasonable to me.
You could orientate yourself by the IRC-client Irssi. It provides the following options:
-ssl: use SSL when connecting-ssl_verify: Verify servers SSL certificate-ssl_cafile <cafile>: File with list of CA certificates (implies-ssl_verify)-ssl_capath <capath>: Directory with CA certificates (implies-ssl_verify)For ZNC a
-ssl_verify-like option could check if the certificate send by the server matches with the certificates installed on the system. And an optional-ssl_capath <capath>-like option could provide a path containing manually downloaded/already accepted certificates.Not being able to verify the servers certificate is currently stopping me from using ZNC, so I would gladly see this feature in future versions.
Yup, I hope to fix this by next release...
-ssl_capathcan't work for us, because ZNC user doesn't have access to file system. But list of explicitly accepted certificates need to be stored somewhere, in some form, of course.How about
-ssl_cafileinstead? Default to the OS-wide/etc/ssl/certs/ca-certificates.crtbundle, and let the user upload their own. That way it also remains compatible with GnuTLS and such, in case ZNC ever wants to use that.Not sure what's better – should the user CAs override, or extend, the global CAs? Option would be nice, as both are useful.