No. But I run with "reject anything that doesn't validate" and
have for several years now and that doesn't suck. We will never
be in a world where all DNS records validate unless we do DNSng and
that DNSng requires that all answers be signed.
Except as a academic exercise, I would never expect anyone would
configure a validator to require that all answers validate as secure.
DNSSEC gives you "provable secure", "provable insecure" and "bogus".
Mark
somewhat rhetorically...
Because of that lost trust, any cross-signed cert would likely be revoked by
the browsers. It would also make the browser vendors question whether the
signing CA is worthy of their trust.
given a list of ca's and certs to invalidate ... how large a list
would be practical in a browser? (baked in I mean)
(not very, relative to the size of the domain system today)
Is this scalable?
(no)
Is this the only answer we have left?
(no)
-chris
(I'm not sure what better answers there are to the situation we are in
today, I do like the work in DANE-WG though... it'll be a while before
it's practical to use though, I fear)
> > Because of that lost trust, any cross-signed cert would likely be revoked by
> > the browsers. It would also make the browser vendors question whether the
> > signing CA is worthy of their trust.
>
> To pop up the stack a bit it's the fact that an organization willing to
> behave in that fashion was in my list of CA certs in the first place.
> Yes they're blackballed now, better late than never I suppose. What does
> that say about the potential for other CAs to behave in such a fashion?The average corporation much prefers to avoid the bad publicity and will
downplay most bad things. Your favorite CA probably included.I think that it's hard to cope with SSL. It doesn't do the right things
for the right reasons. Many of us, for example, operate local root CA's
for signing of "internal" stuff; all our company gear trusts our local
root CA and lots of stuff has certs issued by it. In an ideal world,
this would mean that our gear talking to our gear is always secure, but
with other root CA's able to offer certs for our CN's, that isn't really
true. That's frustrating.
You don't have to have the big fat Mozilla root cert bundle on your
machines. Some OSes "ship" with an empty /etc/ssl, nobody tells you who
you trust.
The reality is that - for the average user - SSL doesn't work well
unless about 99% of the CA's used by the general public are included
as "trusted." If a popular site like Blooble has a cert by DigiNotar
and the Firerox browser is constantly asking what to do, nothing really
good comes out of that ... either people think Firerox blows, or they
learn to click on the "ignore this" (or worse the "always trust this")
button. In about 0.0% of the cases do they actually understand the
underlying trust issues. So there's a great amount of pressure to
just make it magically work.
How about a TXT record with the CN string of the CA cert subject in it?
If it exists and there's a conflict, don't trust it. Seems simple
enough to implement without too much collateral damage.
However, as the number of CA's accepted in most browsers increases,
the security of the system as a whole decreases dramatically. Yet
the market for $1000/year SSL certs is rather low, and the guys that
are charging bargain rates for low quality certs are perhaps doing
one good thing (enabling encryption) while simultaneously doing another
bad thing (destroying any "quality" in the system). SSL is going to
have these problems as long as we maintain the current model.
I like the added "chrome" that the new browsers have for EV certs, but
users need to be stabbed in the face, green vs. blue doesn't really do
it.
In the long run, I expect all the CA's to behave something like this -
especially the ones that have more to lose if they were to become
suddenly "untrustworthy."
Yes, how do you think Verisign/Thawte/Symantec would behave if they
found that their keys were compromised? They might do the right thing,
because they're not stupid enough to think they could get away with
trying to cover it up. What would the browser vendors do in that case?
I hope there's a contingency plan, and if there is it seems like it
should be made public.
Marcus
You don't have to have the big fat Mozilla root cert bundle on your
machines. Some OSes "ship" with an empty /etc/ssl, nobody tells you who
you trust.
And for those OS's (who are they, anyhow) that ship empty bundles,
how many CAs do you end up trusting anyhow?
How about a TXT record with the CN string of the CA cert subject in it?
If it exists and there's a conflict, don't trust it. Seems simple
enough to implement without too much collateral damage.
Needs to be a DNSSEC-validated TXT record, or you've opened yourself up
to attacks via DNS poisoning (either insert a malicious TXT that matches your
malicious certificate, or insert a malicious TXT that intentionally *doesn't* match
the vicitm's certificate)....
> How about a TXT record with the CN string of the CA cert subject in it?
> If it exists and there's a conflict, don't trust it. Seems simple
> enough to implement without too much collateral damage.Needs to be a DNSSEC-validated TXT record, or you've opened yourself up
to attacks via DNS poisoning (either insert a malicious TXT that matches
your malicious certificate, or insert a malicious TXT that intentionally
*doesn't* match the vicitm's certificate)....
And how do you validate the dnssec to make sure that noone has tampered with
it.
> I think that it's hard to cope with SSL. It doesn't do the right things
> for the right reasons. Many of us, for example, operate local root CA's
> for signing of "internal" stuff; all our company gear trusts our local
> root CA and lots of stuff has certs issued by it. In an ideal world,
> this would mean that our gear talking to our gear is always secure, but
> with other root CA's able to offer certs for our CN's, that isn't really
> true. That's frustrating.You don't have to have the big fat Mozilla root cert bundle on your
machines. Some OSes "ship" with an empty /etc/ssl, nobody tells you who
you trust.
You don't have to have a web browser on your machines, either. Also
solves the problem FSVO "solves."
Users don't really want to figure out SSL, and we shouldn't *want* them
to have to figure out SSL. When your grandfolks (or parents or whatever)
connect up to the Internet with a PC, they just sort of expect that things
will work. We should have found a way to make that happen - instead we
gave them SSL. 
> The reality is that - for the average user - SSL doesn't work well
> unless about 99% of the CA's used by the general public are included
> as "trusted." If a popular site like Blooble has a cert by DigiNotar
> and the Firerox browser is constantly asking what to do, nothing really
> good comes out of that ... either people think Firerox blows, or they
> learn to click on the "ignore this" (or worse the "always trust this")
> button. In about 0.0% of the cases do they actually understand the
> underlying trust issues. So there's a great amount of pressure to
> just make it magically work.How about a TXT record with the CN string of the CA cert subject in it?
If it exists and there's a conflict, don't trust it. Seems simple
enough to implement without too much collateral damage.
I don't know. It may have some potential.
> However, as the number of CA's accepted in most browsers increases,
> the security of the system as a whole decreases dramatically. Yet
> the market for $1000/year SSL certs is rather low, and the guys that
> are charging bargain rates for low quality certs are perhaps doing
> one good thing (enabling encryption) while simultaneously doing another
> bad thing (destroying any "quality" in the system). SSL is going to
> have these problems as long as we maintain the current model.I like the added "chrome" that the new browsers have for EV certs, but
users need to be stabbed in the face, green vs. blue doesn't really do
it.
Perhaps what we need is to stab some Internet folks in the face too,
though, for allowing the perpetuation of Much Badness(tm). We might
really be better off, for example, if we could get a ".bank" TLD that
was operated in a rational manner, where only the bank's proper name
was registered, all websites had to run as subdomains, and SSL certs
for .bank could only be issued by ... well maybe even just one CA, or
at most two or three.
I mean, there's still so much wrong with that model too, but it has
some more-correct things built into it.
> In the long run, I expect all the CA's to behave something like this -
> especially the ones that have more to lose if they were to become
> suddenly "untrustworthy."Yes, how do you think Verisign/Thawte/Symantec would behave if they
found that their keys were compromised? They might do the right thing,
because they're not stupid enough to think they could get away with
trying to cover it up.
Wow, you're ... pleasantly naive? (not meant as an insult AT ALL!) Or
maybe I'm just hopelessly cynical. But I do see that as naive; I expect
that at a minimum the spin machine would be running at full tilt and
it would be downplayed as much as possible.
What would the browser vendors do in that case?
Interesting question.
I hope there's a contingency plan, and if there is it seems like it
should be made public.
Okay.
... JG
Steinar,
To pop up the stack a bit it's the fact that an organization willing to
behave in that fashion was in my list of CA certs in the first place.
Yes they're blackballed now, better late than never I suppose. What does
that say about the potential for other CAs to behave in such a fashion?I'd say we have every reason to believe that something similar *will*
happen again
Something similar, including use of purchased (not only limited to
stolen certs), is ongoing already, all of the time. (I had a fellow
IRC-chat-friend report from a certain very western-allied middle
eastern country that there's ISP/state-scale SSL-MITM ongoing there,
for all https traffic.)
The comment on starting out with an empty /etc/ssl is valid. Most of
the normally included CA's you almost never run into on the wild web
anyway. There were some blog postings about this last time a CA was
busted. Shave off 90% of them and you have at least come a bit on the
way (goal 100%).
The absence of proof is *not* proof of absence, and in this particular
case it's pretty safe to assume some abuse is ongoing somewhere, 24/7.
Cheers,
Martin
If this were true, don't you think your friend would provide an SSL cert?
Damian
> > How about a TXT record with the CN string of the CA cert subject in it?
> > If it exists and there's a conflict, don't trust it. Seems simple
> > enough to implement without too much collateral damage.
>
> Needs to be a DNSSEC-validated TXT record, or you've opened yourself up
> to attacks via DNS poisoning (either insert a malicious TXT that matches
> your malicious certificate, or insert a malicious TXT that intentionally
> *doesn't* match the vicitm's certificate)....And how do you validate the dnssec to make sure that noone has tampered with
it.
Since you are from Sweden, and in an IT job, you probably have personal
relations to someone who has personal relations to one of the swedes
or other nationalities that were present at the key ceremonies for the
root. Once you've established that the signatures on the root KSK are good
(which -- because of the above -- should be doable OOB quite easily for
you) you can start validating the entire chain of trust.
Quite trivial, in fact.
I'll note that the PGP "strongly connected set" has grown all the way to 45,000
or so keys in 2 decades of growth. There are several billion Internet users. What
may be workable for Fredrik is probably *not* scalable to Joe Sixpack.
> > > How about a TXT record with the CN string of the CA cert subject in
> > > it? If it exists and there's a conflict, don't trust it. Seems
> > > simple enough to implement without too much collateral damage.
> >
> > Needs to be a DNSSEC-validated TXT record, or you've opened yourself up
> > to attacks via DNS poisoning (either insert a malicious TXT that
> > matches your malicious certificate, or insert a malicious TXT that
> > intentionally *doesn't* match the vicitm's certificate)....
>
> And how do you validate the dnssec to make sure that noone has tampered
> with it.Since you are from Sweden, and in an IT job, you probably have personal
relations to someone who has personal relations to one of the swedes
or other nationalities that were present at the key ceremonies for the
root. Once you've established that the signatures on the root KSK are good
(which -- because of the above -- should be doable OOB quite easily for
you) you can start validating the entire chain of trust.Quite trivial, in fact.
and how about a end user, who doesn't understand a computer at all, to be able
verify the signatures, correctly?
> Quite trivial, in fact.
and how about a end user, who doesn't understand a computer at all, to be able
verify the signatures, correctly?
Joe Sixpack clicks through today. He will, too, later, but, one of
the Fine Things with DANE is that no entity can produce valid data for
anything outside its own domain(s). Damage limitation is quite important,
while admittingly not being the silver bullet.
The existence of a free and secure chain of trust will put a price
pressure on DV certificates, which just might create a situation where
the marginal cost for doing TLS is so low that it is hard to set up a
web site without.
Taken together, this creates a situation where valid, verified
certificates are the norm, for real, which makes it all the more possible
to flag the exceptions much more annoyingly. Perhaps even refuse to
open them.
The current trust model for DNSSEC relies on the vendor of the validator
to bootstrap trust in the root key. This is partly a matter of pragmatism
since the validator is a black-box agent acting on the user's behalf, like
any other software.
It is also required by the root key management policies, since a root key
rollover takes a small number of weeks, much shorter than the
not-in-service shelf life of validating software and hardware. This means
that a validator cannot simply use the root key as a trust anchor and
expect to work: it needs some extra infrastructure supported by the vendor
to authenticate the root key if there happens to have been a rollover
between finalizing the software and deploying it.
Tony.
Tony,
Thanks for this explanation!
I think this is what I've been looking for regarding securing DNSSEC.
*a random php programmer shows*
He, I just want to self-sign my CERT's and remove the ugly warning that
browsers shows. I don't want to pay 1000$ a year, or 1$ a year for that. I
just don't want to use cleartext for internet data transfer. HTTP is like
telnet, and HTTPS is like ssh. But with ssh is just can connect, with
browsers theres this ugly warning and "fuck you, self-signed certificate"
from the browsers. Please make the pain stop!.
--Tei
Once upon a time, Tei <oscar.vives@gmail.com> said:
He, I just want to self-sign my CERT's and remove the ugly warning that
browsers shows.
SSL without some verification of the far end is useless, as a
man-in-the-middle attack can create self-signed certs just as easily.
Really? You can "just connect" with SSH?
root@somebox:~# ssh 1.2.3.4
The authenticity of host '1.2.3.4 (1.2.3.4)' can't be established.
RSA key fingerprint is 03:26:2c:b2:cd:fd:05:fc:87:70:4b:06:58:40:e7:c3.
Are you sure you want to continue connecting (yes/no)?
That's no different that having to permanently accept a self-signed SSL cert...
- Pete
With ssh, you will get a warning if the remote host key is not known, with a fingerprint and advice not to accept it if you don't know if it is correct. This is a direct analog to the warning that the remote host's certificate cannot be verified. In both cases, you are given the chance to accept the key/certificate and continue going; depending on the implementation, you might also be given the option to accept it once or forever. Ssh is actually prone to bigger, uglier, more explicit "you probably don't want to trust this" warnings, especially about things like key changes.
It protects against attacks where the attacker merely monitors the
traffic between the two endpoints.
As you suggest, it does not protect against MITM, but that's different
from being useless.
The value of protecting against the former but not the latter may vary
by situation, but it's not always zero. Not all attackers/attacks that
can sniff also have the capability and willingness to MITM.
(And even SSL w/ endpoint verification isn't absolute security. For
example, it doesn't protect against endpoint compromises. But that
doesn't make it endpoint verification useless.)
-- Brett
He, I just want to self-sign my CERT's and remove the ugly warning that
browsers shows. I don't want to pay 1000$ a year, or 1$ a year for that. I
The warning is there for a *reason* - namely that if you have a self-signed
cert, a first time visitor has *zero* way to verify it's *your* self-signed
cert and not some hijacker's self-signed cert.
just don't want to use cleartext for internet data transfer. HTTP is like
telnet, and HTTPS is like ssh. But with ssh is just can connect, with
browsers theres this ugly warning and "fuck you, self-signed certificate"
from the browsers. Please make the pain stop!.
If you use SSH to connect, and either ignore the "host key has changed" or
"authenticity can't be established, continue connecting?" messages, you get
what you deserve - those are the *exact* same issues that your browser warns
about self-signed certs. And if you *don't* ignore them on SSH - why do you
want to ignore them on SSL?
Note that there's another big difference between SSH and SSL - the number of
people who are allowed to SSH to a given machine is (a) usually small and (b)
pre-identified up front. So if Fred gets an "unknown host key" while SSH'ing
to the server you just set up, that's probably not a big issue because you
presumably know who Fred is and just created an account for him, so you can
supply him with the footprint of the SSH host key to double-verify. That does
*not* scale to Internet-facing web services.
Of course, if you have a *private* *internal* webserver with limited users,
you're free to use a self-signed cert and use your browser's handy "Add
security exemption" dialog and check "Permanent".
