Add per-network option to disable TLS certificate validation #478
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#478
Reference in new issue
Block a user
Validating TLS certificates is great, but let's face it: A lot of networks use self-signed or otherwise "invalid" certificates, and for networks with many servers it's probably not worth maintaining the list of fingerprints in the majority of cases. Lots of networks that do provide their certificate fingerprints do so as SHA-1, not SHA-256, which further adds to the inconvenience.
For most of us, chances are it's not that critical to validate the certificates. Therefore, I propose that each network allow disabling certificate checking, so users can focus on chatting if they want.
Note that this could be implemented as a special
*value, rather than a separate option altogether, as was mentioned on IRC.This looks very insecure to me. Even if you add the first certificate blindly, with luck you will get to the server directly and be protected from MITM.
Why not something like
/msg *status AddTrustedServerFingerprint __ACCEPT_INVALID_CERTIFICATES__and just let znc accept them without having to use a script or whatever to automatically add all the invalid ones.Not sure if it's relevant, but I created a patch that adds a network option to just disable the SSL/TLS cerificate check on a per-network basis for a friend's BNC. For some networks it is impractical to manually trust the cerificates. I know it's not the most secure thing (I wouldn't use it), but most people aren't techsavvy enough to wanna deal with this. (Here's a link: https://github.com/YourBNC/znc/commit/5c74759840e68ef6262aef61dc4f73730f32d74f)
And by "dealing with this" you mean copypasting one line from ZNC's output
in *status about bad certificate back to *status?
2015-02-18 11:12 GMT+00:00 Roelf Wichertjes notifications@github.com:
A friend requested I write that patch for him. Those were his exact words. Someone pointed me to this thread and said that the patch may be relevant.
I want this to be clear: Personally, I agree with you 100%.
But he (correctly) pointed out that most people aren't tech-savvy enough to know what to do (they usually stop reading when the numbers start popping up).
I'm not asking the patch be included in znc main, just noting the patch for people who are interested.
Are they tech-savvy enough to be able to select the relevant setting?
2015-02-18 11:22 GMT+00:00 Roelf Wichertjes notifications@github.com:
He has it off by default. Again, I'm just doing as asked. (I'm already kinda regretting noting it here)
Again, I do not wish to start a fight with you over this, I love the software too much to want to get on the creator's bad side. So I would appreciate if we could both just forget it ever happened.
There's no fight with you :) Also it looks like your patch doesn't
initialize it to true by default.
2015-02-18 11:29 GMT+00:00 Roelf Wichertjes notifications@github.com:
The commit I linked enables verification by default.
I then made another commit that disables it by default as that was what my friend wanted.
If the SSLVerify property is set to true, it does default znc 1.6 behavior.
Also, I'm glad we're okay.
On February 18, 2015 12:36:46 PM GMT+01:00, Alexey Sokolov notifications@github.com wrote:
Sent from my Android device with K-9 Mail. Please excuse my brevity.
And it's probably clear that this would be WONTFIX and closed for me.
YourBNC seems to do this. https://github.com/YourBNC/znc/pull/1
As KindOne- mentioned it is included in YourBNC#1 and would be nice to have for ZNC. I setup a few people with ZNC and they're not tech savvy to play around with certs on their own. Could it possibly be re-considered? Perhaps add a warning when someone attempts to disable.
That would send message that breaking security if TLS is OK which no one wants.
Better question would be: why the network doesn't have valid certificate?
I thought we had this discussion on IRC at one point that if forks want to use that patch they may but the standard ZNC would not have that patch included?
Untrusted TLS is strictly better than plaintext IRC. Sure, you're vulnerable to MITM, but not to passive sniffing attacks. There really should be a way to mark networks as "best-effort SSL" where you acknowledge that you know it's not really secure, but it beats nothing.
Especially today, with Let's Encrypt, there is little reason to have bad certs... but look at it from the user's perspective. They can either use plaintext (which is worse), or manually add a bunch of fingerprints (which they won't check - I know I didn't). That's not ideal.
The browser behavior of "scary warning if invalid HTTPS, no warning if plain HTTP" has always been nonsensical, an artifact of the idea that HTTPS used to be an elite thing that only banks/e-commerce used and a broken cert meant Very Bad Things probably. Nowadays the web is moving towards all-HTTPS, but IRC is lagging behind. I don't think ZNC should fall for the trap of trying to enforce correct TLS certs unconditionally, because what's going to happen in practice is people are just going to switch to plaintext. A lot of server admins already neglect their TLS support (I've seen many servers listed as having TLS on a port which turned out to be closed or unresponsive). Fewer TLS users means they'll neglect it more.
I agree with making SSL cert verification an option, though enabled by default. This is what many clients (hexchat, weechat, etc.) already do. I've been using the YourBNC@5c74759 patch for months and it works completely fine...
In my opinion, being able to choose between three different behaviors would be better here:
Trust all PKI-valid certificates and all certificates added to the fingerprint list by the user. This is the behavior right now.
For the reason that @marcan has pointed out: It is strictly better than plaintext IRC and users might choose plaintext over adding fingerprints manually if there no such option.
Relying on TLS verification via the PKI means trusting a total of more than 600 CAs from all over the world holding over 1000 CA certificates. Some might choose to only trust hand-picked certificates that they verified themselves.
I find such an option to be overkill. The same system of CAs being trustworthy is also what web browsers use to validate content, and having specific filters for IRC only makes the TLS verification setup more tedious instead of less.
Consider this scenario: I connect to an IRC server with a certificate that's not publicly trusted, and I have its fingerprint added to my list of trusted fingerprints. There is no reason why one would need to trust the PKI for that.
Because of the aforementioned shortcomings of TLS, web browsers have HTTP Public Key pinning. Some web browsers even have static lists of CA restrictions for certain sites baked into their executable.
IRC has no such technology. These exact shortcomings of TLS would be addressed by the only-certificates-on-list approach, which is why I believe it to be important.
(edit: wording)
@xnrand sorry for delay, I was busy in real life.
2 questions:
Per-network CA sounds like an option that would give similar benefits compared to whitelisting certain certificates.
But even though it's less effort to use (only one FP needs to be added), I wouldn't necessarily say it's easier. Some CAs have multiple intermediate certificates. When whitelisting a per-network CA, a user would have to choose the correct CA from the certificate chain.
I assume you mean DNSSEC with DANE / TLSA.
I'm not too familiar with the validation procedure when DANE comes into play but my best guess would be that the current normal certificate (chain) validation would simply be replaced with the verification dictated by the certificate usage field iff a TLSA record is present.
Regarding the interaction with this particular issue, if just an option to "disable TLS certificate validation" is added – like the issue title says:
An option disabling TLS certificate validation would probably disable DANE too.
Regarding the approach I personally favor (c.f. my comment and the implementation (PR #1277) of that approach) – giving fine-grained configuration options for validation:
Following that approach, my best guess is another boolean configuration value would be added, named
TrustDANEor similar. The default value would be true. This would allow for:TrustDANEit to false)TrustDANEto true andTrustPKIto false)Oops, yes, of course!
I think this can be merged after DANE (#784)
Disabling the verification completely is a pretty big step back for security. Most IRC networks don't want to pay CA, that's why they use self-signed certs (I know about letsencrypt, but that's not the point). With DANE usage 3 this is not problem anymore, as network operators can add the TLSA record with their current self-signed certificate, ZNC would pick it up and not even bother user with request to verify that cert manually. So the user won't need to disable verification, and still be happy.
DANE would also help with "over 1000 CA certificates" issue, though controlled by network operators, not by the user.
After DANE #1277 can still be useful, but not so much anymore. Mostly for networks which for some reason still don't have TLSA record.
Another minor point: let's rename TrustPKI to something like TrustCommonCertificateAuthorities. DANE usages 0, 1 and 2 still use PKI, but usage 2 ignores those CAs.
-- @kerio92
Hi, I have two networks that set up letsencrypt, but their admins are too stupid to use fullchain.pem, so the certificate fails every 2 months because ZNC can't verify the lone certificate without the full chain being sent by the server.
@kode54 Rizon is like this. I'm sick of having to accept new certificates every couple of months. What is the solution to this?