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.

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.

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.

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

... JG
--
Joe Greco - sol.net Network Services - Milwaukee, WI -  http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

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.

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

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

And for those OS's (who are they, anyhow) that ship empty bundles,
how many CAs do you end up trusting anyhow?

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.

--
//fredan

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.  :-)

I don't know.  It may have some potential.

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.

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.

Interesting question.

Okay.  :-)

... JG
--
Joe Greco - sol.net Network Services - Milwaukee, WI -  http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

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.

--
MÃ¥ns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
Am I in GRADUATE SCHOOL yet?

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.

and how about a end user, who doesn't understand a computer at all, to be able
verify the signatures, correctly?

--
//fredan

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.
--
MÃ¥ns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
... this must be what it's like to be a COLLEGE GRADUATE!!

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.
--
f.anthony.n.finch  <dot*******/
Biscay, FitzRoy: Southwesterly 4 or 5, veering northerly or northwesterly 5 or
6, occasionally 7 later in southeast Fitzroy. Rough or very rough. Rain or
showers. Good, occasionally poor.

Tony,

Thanks for this explanation!

I think this is what I've been looking for regarding securing DNSSEC.

--
//fredan

*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

--
--
â=84±in del â=84³ensaje.

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.

--
Chris Adams <cmadams*******>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

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

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.

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

Someone who can monitor can most likely inject false traffic and thus
MITM.

In any case, a system that is supposed to provide end-to-end security
shouldn't be considered secure if it can be easily bypassed.
--
Chris Adams <cmadams*******>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

No need for (financial) pain, there are free of charge ssl certificates
available, see for example:

http://www.startssl.com/?app=1 http://www.cacert.org/

A big difference between SSH keys and SSL certificates is that SSL certs
have a built-in expiration date (which is a good thing, as nothing is
secure forever).  When that expiration date rolls around, the admin may
create a new key/cert pair, rather than just renewing the previous cert,
which would cause all the visitors that accepted the previous cert to
get a new and nastier warning that the cert has changed.  How do the
visitors know the difference between this case and a hijack/MITM?

Certs are almost guaranteed to change over time as technology changes.
For example, it used to be common to have 512 bit certs with an MD5
signature hash.  Now 1024 bit and SHA1 are the norm, and many are moving
to 2048 bit (and some to stronger hashes).  Having people get used to
periodically accepting a changed cert defeats the purpose of signed
certs (and again, effectively breaks SSL).

--
Chris Adams <cmadams*******>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

eddy stopped issuing

these I hadn't seen... or I had and promptly forgotten about them
since they don't get included in any browser/app/OS :(

Affirmtrust is supposed to start issuing certs 'soon' though, free.

-chris

Huh?  I'm a bit lost here, since I had two StartSSL certs issued
yesterday afternoon.

      Jima

orly? wierd, they made a press release ~last-june (I think?) stating
they were stopping issuance indefinitely. I do hope they are actually
issuing again :)

I like my random numbers to be free.

-chris

< http://threatpost.com/en_us/blogs/ca-startssl-compromised-sa[..] >

has a link to the startssl page about this, which doesn't appear to
load for me (now)... maybe they are back in business!

As claimed by the DigiNotar hacker - He compromised their servers but
Eddy was manually approving certs at the time and so no certs were signed.

There was information about it on the site, but it seems to be gone now.
Articles still show a screenshot of the message you're talking about [1]
, but the site was back alive in July when I needed a certificate.

"A separate notice on another part of the company's site says that its
services would be unavailable until June 20, " [2]

I've certainly been able to issue certificates for myself since then.

[1] http://news.netcraft.com/archives/2011/06/22/startssl-suspen[..]

[2] http://threatpost.com/en_us/blogs/ca-startssl-compromised-sa[..]

indeed, cool! I was able to have a site cert issued lastnight as well.
This is (for me) good news :)

-chris

The problem that I see with browser response to self-signed (or org generated) certs is
not the warning(s) but the assertion that the cert is invalid. Not issued by one of the
players in the Protection Racket does not make the cert invalid. It may be untrustable,
unreliable, from an unknown and/or unverifiable source, but it IS a valid cert. Certs in
a revocation list or malformed certs are invalid.

After all, the Diginotar certs were 'valid', until revoked. Apparently the (arbitrary)
inclusion or exclusion of a root cert by each browser creator or distributer is
equated with validity. By removing the Diginotar root cert, suddenly ALL Diginotar
certs are now reported to end users as Invalid? By refusing to include a CACert root
certificate, no CACert certificate is 'valid'? I think not.

--

-=[L]=-
Hand typed on my Remington portable