Melinda Shore – Advanced DNS Services for Securing Your Application and Enhancing User Privacy.mp4

Melinda Shore – Advanced DNS Services for Securing Your Application and Enhancing User Privacy.mp4


(host)
We’re going to get started here
with our first talk
of this early afternoon session.
And I would just like you all
to help me welcome
Melinda Shore here, who —
[applause]
Thank you. Melinda runs
a cyber security consultancy
and she’ll be talking about DNS.
Hi, my name is Melinda Shore.
To be perfectly honest,
this is my first PyCon,
and I understand it’s a little bit
unusual to give talks here
on what’s basically network
plumbing, network infrastructure.
But we’ve got a library
that makes some new features
in that plumbing available
to application developers
and systems programmers,
and so we thought we would
come here and talk about it,
and also talk about why you should
care, because I think oftentimes
information about what’s going on
doesn’t propagate up the stack.
So the context for this is that
we’ve got a library called GETDNS.
It’s a new DNS library supporting
new DNS protocol features,
because there has been an awful lot
of DNS protocol development
been going on
in the past several years.
The library itself provides
one‑step DNSSEC validation.
It’s asynchronous by default.
It has transfer options
to protect user privacy,
avoid problems traversing
what we call middleboxes,
which are firewalls and NATs
and other sorts of
network transfer intermediaries
that sometimes causes
difficulties for applications.
So our goal is to make
advanced DNS features available
to application developers
without requiring you
to know much about
the protocol details.
It was a project
that was originally —
the API was specified
by Paul Hoffman,
who now works for ICANN,
and Allison Mankin
at Verisign Labs
put together a project
to implement this API.
And it’s involved
a fairly large team,
a very international team
and a very skilled team.
Most of us are are active in the
Internet Engineering Task Force,
or IETF, which is where network
protocols are made and specified.
So that’s the context.
The original specification
was for a C API.
The data structures in the C API
were very Pythonic,
And so we thought, well, we could
put a Python wrapper around this
and get something
that might be easier to use.
And in fact, it’s turned out
to be really nice.
We’ve also got language bindings,
in addition to Python,
for Node and PHP, and there’s
some work going on in Ruby.
We’ve gone to a lot of hackathons
and done extremely well there.
I think the thing that we are
proudest of so far in this project
is that we won the “Best
Internet Security Improvement”
at an IETF hackathon in November.
Anyways, so now we feel like
it’s starting to reach maturity.
We’ve got some really interesting
features in there
and we want to talk
about it in public.
OK, so there are these changes
in network plumbing.
Oftentimes, when this happens,
they’re invisible to users,
but not always —
not in this case.
So we’re going to talk
a little bit about
how this can make your life
a little bit easier.
I’ve got a very, very, very,
very, very brief DNS tutorial.
I’m not sure how many people
are already familiar
with how the DNS actually works.
So I tried to keep it brief
and just provide enough context
for understanding some of the things
that are being built on top of it.
It’s basically a stateless
query‑response protocol.
You send out a message,
and it’s stateless.
A response comes back
and it has enough information
for you to be able to put it
together with your query.
What are sent along
and what are returned
are called resource records.
The structure — it’s basically
an enormous distributed database.
It is hierarchical.
The hierarchy is something that
you’re definitely familiar with.
It starts at “dot,”
which is the root zone.
Then you’ve got the top level
domains, what are .com, .org,
.uk, and hundreds of others.
Second level domains
include things like ietf,
so you’d get ietf.org, python.org,
isoc.org, eff.org,
and then subdomains,
like under “python,”
you’ve got mail, pypi,
ww, and so on.
So what a query looks like
is basically this.
By the way, I said which dig here
because it shows that you’ve got dig
on your Macs already.
It comes with the operating system.
So if you’re interested
in poking around the DNS
and learning a little bit more
about the structure of records
and the data that come back,
this is a good way to do it.
It’s not as good as GETDNS,
but it’s already on your Mac.
OK, so basically what we’re
doing here is we’re saying
dig getdnsapi.net a,
which means we’re asking for
an A record or an IPD4 address
record for getdnsapi.net.
What comes back is
the question that we asked,
which is also circled here,
along with the answer.
Excuse me, the answer is circled.
The question section
is right above it.
So basically the answer that
comes back is 185.49.141.37.
OK, so DNS, it’s ubiquitous.
It’s everywhere.
I mean, I think there are —
I know there are some of us
who remember host.txt and the host
file being distributed by FTP.
But that was decades ago,
and now it’s all dynamic
and it’s being done through this
distributed database called DNS.
But it’s not very secure.
The stateless aspect of it
makes it very easy
for attackers to insert traffic
and to commit what’s called
a cache poisoning attack
in which they insert bogus answers
into your DNS cache,
with obvious consequences.
It means that they can redirect
your traffic pretty easily.
There are also things
they can do along —
doing denial of service attacks
and so on.
So, DNSSEC was developed,
which is a mechanism to prove
the authenticity of a DNS record.
The trust model is based on
the DNS hierarchical structure.
That is to say,
you as somebody who owns a zone,
a domain,
you sign your own records.
Your key is signed
by your parent zone
and so on up to the root.
It uses public key cryptography.
And I don’t know how much —
yeah, this is awesome —
I don’t know how much
you know about crypto,
but in public key cryptography,
you’ve got two keys,
one of which is public
and one of which is private.
And the basic network problem
around public key cryptography —
well, to back up a little bit,
one of the great things about it
is that you can publish
your public key
and make it available,
which means that you don’t need
a pre-existing relationship
with somebody else.
You don’t need
to pre-provision keys,
it has nice scaling properties,
and it’s really nice.
The problem is that, you know,
I could say, “Here’s my public key,
“I’m Angela Merkel,”
and of course, I’m not.
So there needs to be a mechanism
to protect that identity.
The way it’s usually handled
is to have somebody trusted
vouch for the public key and say
yes, you really are Angela Merkel,
although I’m not,
or Melinda Shore,
and they sign it
using their own keys.
Generally — PKI is hierarchical;
DNSSEC is hierarchical.
Some of you may be using
PGP or OpenPGP,
and that is
a slightly different model.
That’s people vouching
for each other,
and it’s more of
a graph structure than a tree.
So here’s a DNSSEC example.
In the query, I’ve said
dig +dnssec getdnsapi.net a.
Get the ipv4 address.
And what comes back is
the address and a signature.
And there are additional records
containing public keys
that I can use
to validate that signature
and prove that the person who —
or the entity
that generated that signature
does in fact have the private key
associated with that domain.
OK, so the first thing we do is
we’ve got this new library, GETDNS,
that makes it very, very easy
to do DNSSEC validation.
You don’t have to know
anything about crypto.
You don’t even really have to
know anything about DNS.
So here, I’ve — there’s
a very short script, simple.py.
We’re importing GETDNS and SYS.
GETDNS queries have a context,
so the first thing you do
is create a GETDNS context.
We create a dictionary
containing extensions
and we’ve asked GETDNS
to return only secure records.
Then we generate an address query
by saying — you know,
doing context.address
on the argument
that’s passed into the script.
And then all we do is,
if we got a good response,
if we got RESPSTATUS_GOOD,
we just walk through the addresses
and we know that everything there
is valid under DNSSEC.
There’s additional data
that comes back as well
if you want a greater level
of detail, but, you know,
as you can see,
this is extremely simple.
So there I run it
against getdnsapi.net.
We get our addresses.
I run it against google.com.
Google doesn’t use DNSSEC
to protect their DNS records.
They’ve opted not to.
So we’re looking at this
and we’re saying, well,
DNSSEC protects public keys for DNS.
Can it protect other stuff?
It securely serves up public keys.
Is this a new trust model
for the Internet?
And so the answer is yes.
OK, so backing up
a little bit to PKI.
As I talked about earlier,
you’ve got to trust somebody.
The way PKI works is that your —
you know, typically,
you’ve got trust roots that come
pre-configured with your browser.
And any certificate that you get
during a TLS section
should chain back up
to a certificate
that’s in your root trust store.
So that means that
browser vendors are the ones
who are making decisions
about who to trust
and who not to, and that hasn’t
always worked out well.
They need to be authentic,
the public keys,
and the people who are using them,
which is you,
need to be able
to prove authenticity
So some of the things
that we’ve been running into
are certificate misissuance.
A very common example is
somebody issuing certificates
for domains that the applicant
doesn’t own.
This happened with TurkTrust, which
was a fairly high-profile example.
And if it chains back up
to somebody who’s already
in your root trust store,
the certificate is going to be valid
even though it belongs to somebody else.
Anyway, we’ve also been running into
careless key usage constraints,
which is certificate —
certification authorities
issuing certificates
that have the CA bitset,
which allows the person
with that certificate
to act as a certification authority
themselves and issue certificates.
We’ve also had problems
with compromised CAs.
And one example that’s getting
a lot of press this week
is the Blue Coat situation.
Have you guys heard about this?
Yeah. It’s a — Blue Coat is —
they make network intermediaries.
They make network intermediary devices,
kind of like firewalls, but it’s…
Reporters Without Borders
in 2013 identified Blue Coat
as an enemy of the Internet
because their devices
can terminate
and reoriginate traffic,
which allows
authoritarian regimes to censor
what the people
in their domains see
and to also do extensive
surveillance on their citizens.
Some of their customers have
included people like Syria and Iran,
China, and so on.
So, one thing
that happened this spring
that was only discovered recently
is that Symantec,
which is one of the largest
certification authorities,
issued a CA cert to Blue Coat.
Blue Coat says
they won’t be using it.
We can believe them or not,
but the issue remains
that somebody — something similar
could happen with somebody else
and we wouldn’t know about it.
I mean, the basic issue is
that if you go out to google.com,
Blue Coat can issue their own
certificate for google.com
and redirect you or censor
what you’re seeing or whatever.
It’s — it will terminate
your TLS section
and reoriginate one
so that it looks real, or not,
but basically, there’s a problem
with censorship and surveillance here.
So this is a problem
that’s built into the PKI.
We know about it and we’re
trying to do something about it
with a number of different
efforts in the IETF.
One of those is called DANE,
which is DNS-Based
Authentication of Named Entities.
We like clever acronyms,
even if it — you know,
it makes things ugly in reality.
“DANE” is easy to pronounce
even if “DNS-Based Authentication
of Named Entities” is not.
OK, here’s the idea.
People are running
their own DNS servers.
They’ve got DNSSEC protection
of their records,
so why not give them control
over what certificates are issued
to represent them, right?
So that when you do a TLS session,
you can retrieve the TLS certificate
from their DNS store
and match it against what you
received on the TLS connection
rather than having to trust
some certification authority.
You still have the problem
of who to trust,
but intuitively,
it’s a lot more comfortable
to trust what a domain says
about their own certificates
than what some third party
with a commercial interest
says about their own certificates.
So the implementation is basically:
put public key credentials
in the DNS protected by DNSSEC.
For TLS, these credentials are —
they’re called TLSA records
and they contain
TLS certificates and entity
certificates, server certs.
OK, so basically,
to authenticate TLS servers,
retrieve a TLSA record from the DNS,
make sure its signature checks out,
compare the certificate
you received with the one
that you receive from the server
in the server_hello.
And in GETDNS, it looks like —
we make a query for a TLSA record
because the context.general
method allows retrieval
of arbitrary record types.
Get the server cert
the same way you currently would.
We’ve been using M2Crypto
because we — at the time
that we were looking,
which was about two years ago,
a year and a half ago,
M2Crypto really had
the best interface,
the most complete interface
to certificate services.
Pull data out of the record.
This looks like a lot of lines,
and it’s a lot of lines
because that’s a lot of data,
but you can see
that it’s not doing anything
particularly sophisticated there.
Compare it with what you’ve got,
and either it matches
or it doesn’t.
We have a ton of sample code
up on — in our GitHub repo.
Other DANE applications
include OpenPGP keys,
S/MIME keys, and people are now
using TLSA to protect SMTP sessions.
In particular, in Germany
there’s been very, very broad
deployment of TLSA records
and valid ones as well.
We’ve also got an example
of code that —
we’re calling it DANE encrypt.
We’re using S/MIME certificates
to encrypt email
based on certificates
that are stored in a TSLA record.
There’s now an OpenPGP type.
And since we’re running
a little bit short,
I thought I’d move ahead
to DNS privacy.
After the revelations
about Edward Snowden came out,
the IETF took a good hard look
at what was going on
and published RFC 7258,
which says that pervasive monitoring
is a technical attack on the network,
and we’re taking great care now
to protect protocols
against possible privacy leaks.
This includes encryption,
but it’s not limited to encryption.
There’s a lot of metadata
out there that —
where observers can make inferences
about what users are doing
based on their behavior.
DNS in particular leaks
a massive amount of information
about what a user is doing
in the network.
So in parallel with protocol
development work in the IETF,
we’ve been implementing this
in GETDNS.
That includes things like
adding TLS transport.
The RFC specifying the use
of TLS for DNS transport
was just published
a couple of weeks ago.
We’ve implemented it already.
It’s available on a few servers
but not many.
We’ve also added optional padding
so that an observer cannot tell
how large your query is, and so on.
Also, just as a quick note
on roadblock avoidance,
middleboxes such as
firewalls and NATs
sometimes filter out DNS traffic
that they think is hinky.
So we’ve got mechanisms
to work around these.
This is completely transparent
to the programmer.
This is not something that you
would need to do anything to use,
but you should know it’s there.
OK, current status.
We’re now feature complete with
respect to the original API spec,
and we’ve got ongoing integration
of new protocol features
as they’re being issued
by the IETF.
One of the things that we’ve been
really, really happy about
using Python for doing this
is that it’s been incredibly quick
to prototype new protocol features
in the DNS using this.
I mean, on the order of hours.
You can just sit down at the REPL,
construct a packet,
and push it out, and there you go.
So that’s been
a really wonderful feature.
So we’ve got —
the project homepage
is getdnsapi.net.
We’ve got the GitHub repo, PyPI.
I put together a docker image,
and I actually am really
interested in feedback on this.
Some people have found it
difficult to build the bindings
because of dependencies,
particularly dependency on libgetdns,
and so I put together a docker image,
and it’s seen very little download,
not nearly as much download
as the source code itself.
And if people feel strongly
one way or another
about using docker
for this sort of thing,
I’d be very interested
in hearing your feedback.
OK, we’ve got a mailing list.
Please feel free to join it.
And we’ve got an upcoming
hackathon in July in Berlin,
and we’re going to have
a team there as usual.
And we’re really looking
for participation
from application developers
about what kinds of things
that they’d like to see
to help them secure their protocols
using some of this technology.
So please feel free
to drop us a line and get involved.
You do not need to be
registered for the IETF meeting
or participating in the IETF
meeting, you just need to be there.
It’s a Saturday and a Sunday.
Some of the things
we’ve got in mind
include a GETDNS protocol
for Twisted,
a DANE API so that you don’t
even have to know
as much as I showed you
right there.
You don’t have to do
any of the crypto stuff yourself
or use the M2Crypto interface.
Or whatever ideas
you may have as well.
It’s a very, very open process.
And that’s the URL
for the hackathon itself.
That’s my Twitter handle.
And do people have questions?
[applause]
(host)
Yeah, could I please ask folks
to line up at the microphone,
and remember to ask questions.
Thank you.
(Melinda Shore)
Hi.
There’s no sound from that mic, eh?
(host)
Is the microphone on? There we go.
(audience member)
Firefox ships with its own
search store, I think.
Other browsers
kind of defer to the OS,
or maybe they ship
some of their own.
If you don’t check the integrity
of that download,
then are you kind of opening yourself
up to a bunch of vulnerabilities?
(Melinda Shore)
I’m sorry, I can’t hear that.
(audience member)
So, the authentication, like —
you were talking about PKI.
So you’ve got some root cert
that you’re going to trust.
And that root cert is embedded
in, like, the Firefox download.
So when you’re downloading
that Firefox download,
you make sure that you’re not
getting a malicious copy
that has an incorrect
root cert store.
So you kind of have, like,
a chicken and an egg problem here.
How do you resolve that?
(Melinda Shore)
Well there’s a couple of things going on
actually in that space. There’s the —
first off, we assume that Mozilla
is making good decisions
about what ends up in the cert store,
and generally they have.
But there are incidents
where a CA is compromised
or they’ve made a mistake
and there needs to be
the ability to respond to that.
So the root trust store is —
yeah, I mean, that’s — as I said,
there’s a bunch of different stuff
going on around that right now.
I don’t know if you’ve heard about
the Certificate Transparency Project,
which allows you to audit
what you’re seeing and make sure
that other people
are seeing the same thing.
And we’re also doing
some work around that
on this project as well,
but it wasn’t relevant to this talk.
This is a little bit different.
You know, right now,
one of the things that’s been
delaying implementing
this kind of thing
in Firefox and in other browsers
is that it introduces
additional latency
into session startup, right,
because you’re —
when you’re having to do
a bunch of DNS queries.
So, another thing we’re doing is
a TLS protocol extension
that allows the server
to send down the entire
DNSSEC validation chain
along with the certificate,
and that was just accepted
as a TLS working group deliverable.
And I’ve actually got
an application into MAS
for funding to support this —
implementing it.
So there’s a movement,
you know, right now.
This is a very transitional time,
and yeah, we’ll see what happens.
I’m hoping that — you know,
the Chrome guys are involved
in this as well, so…
(audience member)
Yeah, I really like the idea of DANE.
It sounds awesome.
My question was along the lines
of what you just said.
What sort of timeline
do you think we would see
before we see it
in any of the major browsers?
(Melinda Shore)
Yeah, I think — you know,
I’m hoping that we can
actually have a beta.
I’m hoping we can have
something out in Firefox
within about six months or so
that will do the DNSSEC extension,
and that’ll enable DANE and DNSSEC
and some of these other technologies.
Right now, I mean, the browser
vendors are so sensitive to latency,
and you can’t blame them, so…
(audience member)
Thank you.
(audience member)
The Blue Coat CA cert,
could that then further issue
more CA certificates?
And what would be the repercussions
if that sort of got out?
(Melinda Shore)
This specific certificate
cannot issue
additional CA certificates
because it’s got — I don’t know
how much you guys know about PKI
and what’s in the X.509 certs,
but it’s got a path length of zero,
which means that it can only issue
end entity certificates.
But, you know, this is —
the attack is a broad one
and somebody else could issue
one with no path length,
which means that anybody
under them could — you know,
they could issue CA certificates.
Right now, this specific
certificate cannot.
(audience member)
I guess, what would the protocol be
if something somewhere
under the Symantec tree
leaked with that ability.
Would that invalidate everything
up to the top?
(Melinda Shore)
I’m sorry?
(audience member)
If somewhere under Symantec’s tree,
a CA with no path line was leaked,
would they generally then
have to invalidate everything
up to the top?
(Melinda Shore)
What happens is,
the path length is checked
as part of the validation,
and it starts at the bottom,
and as soon as you hit
an invalid path length,
you’re done. It’s no longer valid.
So, typically CA certificates
do not contain path lengths,
I believe, but I’m not really sure.
I mean, it’s not really
that heavily used,
that particular field.
So we were kind of surprised
to see it in the Blue Coat cert,
and it was just one of these things
that makes you wonder
what the heck they’re doing
and why they would issue
a certificate
that looked like that.
(audience member)
Hey, quick question.
So you said
that you have to trust somebody,
and currently we have
the CA trust system.
With DNSSEC,
it wasn’t entirely clear to me
who we’re trusting there
and why they are more trustworthy
than the current checks
and balances we have.
(Melinda Shore)
Sure. Typically, when a DNSSEC record
is going to be signed by a zone —
by the domain that owns —
I mean, basically, you’re going to be
signing your own records, right?
Your key is going to be signed
by your parent zone and so on,
up to the the root zone.
And this is an intuitive thing,
I don’t think you can really
prove it, but the assumption here
is that people are going — not —
people are going to be disinclined
to make false assertions
about their own records, right?
And they’re not going —
you know, if I’m nomountain.net,
I cannot make assertions about
google.com because it won’t validate.
So there’s a little —
it’s a little bit cleaner.
But again, you know,
the assumption is
that a CA is going to tend to be
more problematic to deal with
in terms of validating signatures
and in terms of
legitimacy of relationship
than you are about yourself.
I mean, how —
if you are blah.co.uk,
how does — how would a .com —
how would a CA
in the .com domain
be entitled to issue
certificates to you?
I mean, how is anybody entitled
to issue certificates to you?
That’s the basic problem here
is we don’t really know
what the relationships are
when a certificate is issued.
We, you know, we can assume
that a CA has good practice,
but that’s really a business
question and not a technical one.
(audience member)
So if I have a .io, for instance,
then is that as trustworthy
as having a CA cert
that’s maybe in the Firefox store?
(Melinda Shore)
Well it’s — you’re going to be —
you’re going to be making
assertions about your own records,
and you’re not
going to be making assertions
about anybody else’s records
because they won’t validate, right?
Whereas a commercially purchased
certificate from a CA,
we don’t know what the relationship
between you and them is
or if it’s even valid.
You know, there have been
instances of CAs issuing
microsoft.com certificates
and google.com certificates
to entities other than
Microsoft and Google.
And there’s no way
in the PKI system —
well, there are name constraints
but they’re not heavily used.
But, you know, it’s —
the current PKI system
doesn’t really support
expressing that relationship,
which is a trust one.
(audience member)
OK, thanks.
(host)
I think we have time for one more question.
(Melinda Shore)
Yeah, I’ll be around afterwards
if people want to chat.
(audience member)
Is there some responsible group
or entity or volunteer project
or something
that’s monitoring the collective
set of CA certificates
that are going out
with all the browsers
and the JVMs and everything?
(Melinda Shore)
Yeah, there’s something called
the CAB Forum,
the CA and Browser Forum,
and they tend to be the ones who are
setting policy around this stuff.
It’s — of course, compliance
is always voluntary, right?
And since the incentives
for behaving badly
are pretty high,
we need mechanisms
to number one, mitigate those
and number two, monitor those,
and the latter of which is what
certificate transparency is all about.
So anyway, I will put
the slides up somewhere
and tweet it
and make those available
so that you’ll have the URLs
to get the software.
And as I said, I’m really curious
about how you all feel
about docker and what facilities
you would find useful
as application and developers
and systems programmers.
So, thank you very much.
I really appreciate your time.
[applause]

Add a Comment

Your email address will not be published. Required fields are marked *