

Enhancing SSL Security for IRC: DANE Support - ptrf
http://ahf.me/articles/2013/09/14/enhancing-ssl-security-for-irc-dane-support/

======
giovannibajo1
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.

~~~
ptrf
Using DANE in tandem with DNSSEC ensures that such changes wouldn't go
unnoticed.

~~~
giovannibajo1
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](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.

------
gwu78
"... 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.

~~~
ahf
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/](http://censurfridns.dk/)

------
planckscnst
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.

~~~
ahf
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.

