Enhancing SSL Security for IRC: DANE Support(ahf.me)
ahf.me
Enhancing SSL Security for IRC: DANE Support
http://ahf.me/articles/2013/09/14/enhancing-ssl-security-for-irc-dane-support/
3 comments
The only problem with DANE is that it doesn't protect from NSA. You are simply moving trust from CAs to your TLD owner. Whoever controls your TLD (and whoever can subpoena them) is able to change your zone file without you realizing it.
Yeah, that's true; DANE does not add anything to the encryption of the protocol itself.
The point of this is to, hopefully, slowly get people to start actually verifying certificates instead of just randomly assuming that they are secure.
The point of this is to, hopefully, slowly get people to start actually verifying certificates instead of just randomly assuming that they are secure.
Using DANE in tandem with DNSSEC ensures that such changes wouldn't go unnoticed.
Why do you think so? Let's assume I have complete control over a TLD zone file (.com), into which you inserted the DS records of your DNSSEC-signed domain (example.com). Let's say my goal is to MITM users connecting to https://www.example.com relying on DANE for trust of TLS certs.
I surely cannot modify the records in your signed zone because I don't have your KSK/ZSK private keys. What I can do instead is preparing a duplicate of your zone, signed with a freshly-generated KSK/ZSK pair; in that zone, I will change only the DANE records (or also the A records, depending on the kind of MITM attack I need to mount), and I will sign everything with my new keys. Then, I start MITM'ing my target so that:
* DS records replies for example.com contain the DS record for my own KSK/ZSK keys.
* NS records replies for example.com direct to my own nameserver (or even simply MITM the glue records, depending on the nameserver setup).
* My nameserver will reply as authoritative for example.com, and will serve the modified zone, which will be fully DNSSEC validated.
I surely cannot modify the records in your signed zone because I don't have your KSK/ZSK private keys. What I can do instead is preparing a duplicate of your zone, signed with a freshly-generated KSK/ZSK pair; in that zone, I will change only the DANE records (or also the A records, depending on the kind of MITM attack I need to mount), and I will sign everything with my new keys. Then, I start MITM'ing my target so that:
* DS records replies for example.com contain the DS record for my own KSK/ZSK keys.
* NS records replies for example.com direct to my own nameserver (or even simply MITM the glue records, depending on the nameserver setup).
* My nameserver will reply as authoritative for example.com, and will serve the modified zone, which will be fully DNSSEC validated.
"... where the client relies on a trusted source (their ISP's DNS server..."
Well, for several major ISP's, maybe even most ISP's worldwide, you can't trust them not to use their DNS servers to show you ads or a sponsored "search engine" if you type a domain name that is not registered.
If a user really wanted a "trusted source" for DNS RR's she would be best to contact the appropriate authoritative nameserver directly, not an ISP's resolver.
Well, for several major ISP's, maybe even most ISP's worldwide, you can't trust them not to use their DNS servers to show you ads or a sponsored "search engine" if you type a domain name that is not registered.
If a user really wanted a "trusted source" for DNS RR's she would be best to contact the appropriate authoritative nameserver directly, not an ISP's resolver.
It's true that we still haven't secured the connection between the user and his ISP's DNS server, which I agree is a problem. DNSSEC only helps between the DNS servers themselves.
We are now down to either a) run your own DNS server locally on your machine or b) use a third-party DNS server that we trust.
Personally, I use Thomas' (the person mentioned in the article itself) free, uncensored, DNS service called CensurFriDNS. You can read more about it here: http://censurfridns.dk/
We are now down to either a) run your own DNS server locally on your machine or b) use a third-party DNS server that we trust.
Personally, I use Thomas' (the person mentioned in the article itself) free, uncensored, DNS service called CensurFriDNS. You can read more about it here: http://censurfridns.dk/
So, in my office, we needed a way to communicate passwords with each other; we hadn't gotten everyone on board the GPG train yet, so we setup an IRC server with SSL for that purpose.
...then we found out someone was connecting to it with a web-based IRC client.
...then we found out someone was connecting to it with a web-based IRC client.
In the recent weeks, there have been a lot of discussions about security on IRC and the use of web-based IRC clients in particular.
The general opinion appears to be that people really don't give a rat's ass about securing themselves on IRC. People run IRCd's and their IRC clients on multi-user shell services for a suspicious little amount of money per month just to be able to claim they have their own server and to get a cool virtual host from the huge list that many of these shell providers have.
Recently people are starting to use "bouncer" like web services that keeps them connected even when their browser isn't attached to their session. This basically means that you do not own your connection to the IRC server which also have security and privacy implications.
We can't change people over night, but hopefully we can slowly plant a seed that will make people think about what they do and how they do it.
The general opinion appears to be that people really don't give a rat's ass about securing themselves on IRC. People run IRCd's and their IRC clients on multi-user shell services for a suspicious little amount of money per month just to be able to claim they have their own server and to get a cool virtual host from the huge list that many of these shell providers have.
Recently people are starting to use "bouncer" like web services that keeps them connected even when their browser isn't attached to their session. This basically means that you do not own your connection to the IRC server which also have security and privacy implications.
We can't change people over night, but hopefully we can slowly plant a seed that will make people think about what they do and how they do it.