Thousands of SSL Certs Issued To Unqualified Names

Trailrunner7 writes "The recent attack on Comodo and several of its associated registration authorities has spurred quite a bit of re-examination of the way that the Web's certificate authority infrastructure works--or doesn't. One interesting result of this work is that the folks at the Electronic Frontier Foundation have discovered that there are more than 37,000 legitimate certificates issued by CAs for unqualified names such as 'localhost,' or 'Exchange,' a practice that could simplify some forms of man-in-the-middle attacks. 'Although signing "localhost" is humorous, CAs create real risk when they sign other unqualified names. What if an attacker were able to receive a CA-signed certificate for names like "mail" or "webmail?"' Such an attacker would be able to perfectly forge the identity of your organization's webmail server in a "man-in-the-middle" attack!'"

Comments

No news here

[energizer-bunny2]

How is this new? People have been using internal server names (fully qualified and not) for a long time.

In fact, Microsoft Exchange "best practices" state you should be using the unqualified server name as one of the SAN entries in the SSL cert.

Re:No news here

[6031769]

It is new because you would issue a cert for the internal host from your own internal CA. In this case a remote, third-party, seemingly trusted CA has issued a cert for an unqualified host. That's a massive difference and a huge cause for concern.

Re:No news here

[energizer-bunny2]

Or, maybe you just get a real certificate issued so you don't have issues when...say...the CEO uses his iPhone or other mobile device internally.

Re:No news here

[snsh]

Our organization used to get wildcard SSL certs from Digicert for our internal AD domain. It was great for a while - we could enable SSL on internal servers without getting a browser warning and without having to set up our own CA/PKI. But Digicert recently pulled the plug and switched us over to SAN certs. They said the CA forum doesn't allow members to issue wildcard certs anymore for .local type domains.

I don't quite understand what difference it makes.

Re:No news here

[Spad]

Sounds like the ideal reason to be using an internal CA to me.

Re:No news here

[energizer-bunny2]

To avoid "this is an un-trusted root CA", you should use a public cert.

Is it better to setup the cert properly to not give errors, or teach your users to ignore them?

Re:No news here

[Anonymous Coward]

Because .local is a valid TLD that could be used in the future. Current MS advice is that your domain should be of the form corp.example.com where example.com is any domain you legitimately own.

Re:No news here

[Spad]

I'd rather teach users to get IT to install our internal CA certs onto their devices before they'll connect so that all the other internal services signed by our CA will work correctly as well.

Of course, we could just pay some "trusted" chimps for a wildcard cert for our internal domain, but having our own certificates with direct control over them and the ability to issue whatever we need when we need it is somewhat preferable.

Re:No news here

[bsDaemon]

You know you can add your internal CA to the trust chain and take care of the problem without having to abuse the system, right?

Re:No news here

[Anonymous Coward]

It's not practical to set up an internal CA for a small company. And yes; it is Microsoft recommended best practices for Exchange 2007, SBS2008, etc.

Re:No news here

[Sloppy]

"set up the cert properly" means to tell the mobile device about your CA.

Re:No news here

[h4rr4r]

It takes a few minutes on a linux netbook. I think any company can afford 15 minutes and a $250 netbook.

Re:No news here

[Anonymous Coward]

It is a whole 30 minutes worth of work with no associated cost. What a PITA, right?

Re:No news here

[Anonymous Coward]

Hell, it takes 20 seconds of GUI clicking on Windows. If for some reason they're not in a domain.

Re:No news here

[TheRaven64]

.local. is a valid TLD that is used NOW. It is used by multicast DNS. All devices on the local network that support mDNS are expected to advertise themselves in the .local domain.

Re:No news here

[kasperd]

In fact, Microsoft Exchange "best practices" state you should be using the unqualified server name as one of the SAN entries in the SSL cert.

A widely trusted CA shouldn't issue certificates for unqualified hostnames. It is a bad practice. And if a document calls a bad practice for a best practice, I'll question the validity of said document.

However, I think the main target for criticism should be the SSL clients. When a client access a domain name that is not fully qualified, it should expand it to a fully qualified domain name before validating the certificate. The concatenation of unqualified hostname and DNS search path happens on the client machine. I don't see any good reason for using this concatenation for DNS lookup but not for validating the certificate. Ideally the resulting hostname would be visible to the user. For example for URLs in a browser, I would make the browser implicitly redirect to the fully qualified hostname. In fact such an implicit redirection would be a good idea even for http requests. Using unqualified hostnames has a drawback because the http server may only have the fully qualified version configured, the administrator might not always know about the use of a DNS search path since clients need not be on the same network as the server.

If clients would always use the fully qualified domain name for validating certificates, then there would no longer be a reason to issue certificates with unqualified hostnames.

One question remains, can clients mistake what was intended as an unqualified hostname for a fully qualified hostname. (I don't know if the representation in the certificates use a trailing dot to distinguish the fully qualified hostnames from unqualified hostnames). If the clients cannot tell the difference, this could be a security problem. A heuristic that is used in many places is, that if there is a dot somewhere in the middle of the hostname it is a fully qualified hostname, and otherwise not. However even if there is multiple components separated by dots, you can still append a DNS search path. And a hostname with a single component can be a valid fully qualified hostname. A few TLDs actually have A records for the TLD (all cases I know of will redirect to the administrator for the TLD).

Re:No news here

[repetty]

Yeah, I'm going to have to disagree with you on this one.

Software-wise, it's free or nearly so. You can do it low tech by managing your CA activities via the Linux/Unix command line or you can use more elaborate GUI packages that are available.

Very doable.

Now, I will concede that just about any upper-level manager in any IT organization that you might happen to ask would agree with you but they're just holding out for more funding -- that's just their natural knee-jerk reaction.

Re:No news here

[h4rr4r]

But this mythical small company might not be able to afford such expensive products.

Note, that was sarcasm.

Re:No news here

[kasperd]

Is it better to setup the cert properly to not give errors, or teach your users to ignore them?

If you want nonstandard certificates, you should setup your own internal CA and add that CA as trusted on the devices where you need it. Devices where you cannot add a CA shouldn't be using SSL to access unqualified hostnames. In those cases get a certificate for the fully qualified hostname, and configure the device to use that.

Re:No news here

[fishbowl]

It's practical to setup an internal CA for a *small* company, since you don't even need the CA in the first place, you just need self-signed certs, and you can explicitly accept these certs on each desktop. What can be tricky is putting your internal CA into a large enterprise, where you have the dilemma of needing access to keystores or requiring users to accept untrusted certs on the assumption that they are from your internal CA.

Re:No news here

[Anonymous Coward]

I'm curious: how do you manage the certs on the iPhone? Specifically, how do you remove that company root cert if you leave the company?

Re:No news here

[BitZtream]

Yea, its uber tricky ... if your using an OS that wasn't actually designed for enterprise use.

I freaking hate defending MS, but in a domain/active directory setup, running your own internal CA is painless. The CA cert is automatically pushed to all machines in the domain so the domain can function properly anyway so every windows machine is covered by default. Cert expired? no biggy, republish, click click click, entire domain updates within 24 hours, small offices within minutes.

Users don't need to know anything about CAs or certs, the OS and servers do their job and take care of all that for you.

Unix machines aren't as nicely integrated into ActiveDirectory so you have to manage those some other way, but if your a company of any size at all, you've already got a way to manage your unix boxes don't you?

Running your own CA is only an issue if you don't know what you're doing, i.e. not an admin, just someone who plays one for their local business who doesn't know any better. If you have a clue, its not particularly difficult.

Of course, the fun flip side to that is ... I can and have issued a fully trusted cert sites outside our network in order to snoop on encrypted traffic via an SSL bouncer, and since the cert is signed by our internal CA, everyone validates it just fine.

Re:No news here

[energizer-bunny2]

You should also add in the time it takes to install that cert on every device.

There are 2 basic attitudes I see here:
1. Who cares if the user gets errors, they should have installed the cert
2. Just set it up according to Microsoft's recommendations and not have users complain.

#1 will result in numerous calls to whatever helpdesk is available. In the extreme, you get the owner/ceo/exec/etc... barking at you because they don't understand the error message. Or, you use an internal CA and have to manually manage all devices. What do you tell the owner when they get a new phone on Sunday morning and ask you why they can't just set it up.

#2 results in no errors for the end user...it just plain works. The only ones who seem to have a problem are engineers/techs that don't seem to care what the end-user experience is.

You can go about this either way. It's your choice.

I prefer to setup systems so that users don't need to call me every time they get a new device, computer,etc. That is what the autodiscover service is for!

Re:No news here

[rootofevil]

http://www.apple.com/support/iphone/enterprise/

Re:No news here

[cbiltcliffe]

You should also add in the time it takes to install that cert on every device.

If it's a small company that doesn't have the money to set up their own CA, which was the initial basis of your argument, then they also won't have hundreds or thousands of devices to import the CA cert into. If they have a dozen employees, then it'll take all of 45 minutes to install the cert on an iPhone for all of them.

There are 2 basic attitudes I see here:

1. Who cares if the user gets errors, they should have installed the cert

2. Just set it up according to Microsoft's recommendations and not have users complain.

#1 will result in numerous calls to whatever helpdesk is available. In the extreme, you get the owner/ceo/exec/etc... barking at you because they don't understand the error message. Or, you use an internal CA and have to manually manage all devices. What do you tell the owner when they get a new phone on Sunday morning and ask you why they can't just set it up.

The user shouldn't have installed the cert. If the user can install certs, then you've got much bigger security issues than an error message in the browser. The IT person/department/support company should install the cert. You also don't have to manually manage all devices. I love these people that think they know enterprise IT, because they can plug in a printer and share it between their two home PCs.

Most devices allow some type of remote, group policy based management. If they don't, they really don't end up in businesses. Windows machines can have the cert added by group policy from the domain controller. Blackberry devices have a management platform that allows for similar group control. iPhones have it, too, from what I understand, although I don't support them myself, so I have to go on input from others.

And when the owner gets his new phone, and wants to set it up to check his email on Sunday morning? You tell him that unauthorized devices aren't allowed to connect, to protect his executive bonus from being rerouted to a cracker's swiss bank account. You can relax the security measures, if he puts in writing that he's ok with losing his bonus to crackers. Otherwise, you can set up the phone for him first thing Monday morning when he gets to work.

#2 results in no errors for the end user...it just plain works. The only ones who seem to have a problem are engineers/techs that don't seem to care what the end-user experience is.

You can go about this either way. It's your choice.

I prefer to setup systems so that users don't need to call me every time they get a new device, computer,etc. That is what the autodiscover service is for!

A good end user experience for wireless networks is for any user-provided device to just be able to connect to the network with a click or two, and immediately be able to access anything they need. Of course, this means that your wireless has to be completely unencrypted, with no firewalls protecting anything at all, no passwords required for access, or what have you. Because if there was even a slight impediment to the end user, it would be a bad user experience.
Is that seriously what you're recommending?

Security practices are there for a reason. Sometimes you get overbearing idiots who want a 78 character alphanumericspecial password with no repeated characters, no writing it down, and you have to change it every week, true. Overreaching "security by rulebook" is sometimes counterproductive.

But having "legitimate" CA providers giving out certs for "mailserver" and equally generic hostnames, is downright dangerous. You can do that kind of thing safely with your own CA, because after you've imported the CA cert into your devices, your "mailserver" cert will be allowed, but not some MITM cracker's "mailserver" cert, because it wasn't generated by your CA. Your CA is only recognized within your organization, on your own devices.
When Comodo, Verisign, or anybody else is generating "mailserver" certs, then absolutely anybody with a browser is at risk of their "mailserver" being impersonated by anybody else's "mailserver" cert, because the CA is publicly recognized.

Re:No news here

[Amouth]

One easy way that we use (small company here) is that iTunes will sync trusted CA's from the paired computer to the phone so any office laptop has our CA on it and iTunes will sync it to the phone which then sees it..

As for removing it when they leave - the phone is ours.. we keep it and wipe them.

Re:No news here

[energizer-bunny2]

no, I am not suggesting you use un-encrypted wireless and most certainly not suggesting we get rid of firewalls either.

I am suggesting that there are way too many techs that forget how to take care of the end user and make their experience an easier one.

Re:No news here

[mvdwege]

In fact, Microsoft Exchange "best practices" state you should be using the unqualified server name as one of the SAN entries in the SSL cert.

A widely trusted CA shouldn't issue certificates for unqualified hostnames. It is a bad practice. And if a document calls a bad practice for a best practice, I'll question the validity of said document.

Wouldn't be the first time MS has a very 'interesting' interpretation of best practice. Remember how long it took for Exchange to stop using 'accept-then-bounce' instead of outright rejecting the SMTP session for an unknown recipient?

Mart

Re:No news here

[DavidRawling]

Wouldn't be the first time MS has a very 'interesting' interpretation of best practice. Remember how long it took for Exchange to stop using 'accept-then-bounce' instead of outright rejecting the SMTP session for an unknown recipient?

Remember though the reasoning for that - rejecting immediately allows for a reasonably high-speed dictionary attack to harvest the email addresses in the organisation. Remember also the timing of that decision - the 90's, not the late noughties. For example, consider the following approach:

• Connect to mail server
• Attempt to send to a dozen common names - "Bob@domain", "Jim@domain" - if any succeed, assume the email format is FirstName@domain; use dictionary of first names to harvest addresses
• Attempt to send to InitialSurname - "BJohnson@domain", "TSmith@domain" - if any succeed, assume the email format is InitialSurname@domain; use dictionary of first names to harvest addresses
• Attempt to send to Initial.Surname - "B.Johnson@domain", "T.Smith@domain" - if any succeed, assume the email format is Initial.Surname@domain; use dictionary of first names to harvest addresses
• Attempt to send to FirstName.Surname - "Bob.Johnson@domain", "Ted.Smith@domain" - if any succeed, assume the email format is FirstName.Surname@domain; use dictionary of first names to harvest addresses

It's surprising just how many addresses you can find and harvest given one or two matches even assuming the above, simplistic algorithm. Nowadays, yes, we all do outright rejection, we use greylisting, we use reputation services. It's a different Internet.

Re:No news here

[mvdwege]

Stop being an apologist.

1. Spammers don't use dictionary attacks. They just throw a purchased list of addresses at your mailserver.
2. In the nineties 'accept-then-bounce' might have been acceptable, but this behaviour was default until the previous version of Exchange, when rejecting already was best practice for almost a decade.

There is no excuse for this behaviour.

Mart

Re:No news here

[kasperd]

Remember though the reasoning for that - rejecting immediately allows for a reasonably high-speed dictionary attack to harvest the email addresses in the organisation.

This is a terrible reasoning. Yes, it does increase the resource usage for dictionary attacks a bit. However, it increases the resource usage for the server even more. In addition it causes innocent bystanders to be flooded with bouncing messages.

If you want to slow down somebody scanning for valid addresses, then just delay the responses to the originating IP every time an attempt to send to a nonexisting address is made.

Re:No news here

[cbiltcliffe]

And the easiest end user experience is inevitably the one with zero security.

So yes, that is what you're advocating. You just don't want to admit it, or maybe don't even realize it yourself.

Easy fix

[Anonymous Coward]

Software should automatically reject certificates for unqualified names, even if properly signed.

Re:Easy fix

[Richard_at_work]

That has the potential for ruining plenty of intranet applications, which can also be SSL protected.

Re:Easy fix

[eggled]

Intranets can run their own CAs - that's the Right Way to do it, not to issue a public cert for a private domain.

Re:Easy fix

[Richard_at_work]

Read the post I replied to - his argument was that software, i.e. browsers, should reject properly signed certificates if the domain signed for is unqualified. Thats different to your argument, which I agree with, as running an internal CA would not negate the original suggested remedy.

Re:Easy fix

[eggled]

Righto - I misread his as the CAs should reject certs for unqualified domains. But then, how can a browser determine unqualified vs. qualified? The DNS server is the authoritative record of domains, so unless you override to an external DNS server, you are not going to impact intranet software.

Re:Easy fix

[Richard_at_work]

A browser can already tell the difference between qualified and unqualified - it has nothing to do with DNS itself, and everything to do with the presented domain. "myhost" is unqualified, and "myhost.example.com" is qualified - it doesn't matter if "example.com" exists in the wider DNS system, thats not even checked.

Because you cannot advertise unqualified domains on the wider DNS system, its typically called the intranet zone, and IE in particular uses it to raise the trust level (for example IE may present NTLM credentials to an unqualified domain but not a qualified one, because unqualified domains are internal).

Re:Easy fix

[arth1]

A browser can already tell the difference between qualified and unqualified - it has nothing to do with DNS itself, and everything to do with the presented domain. "myhost" is unqualified, and "myhost.example.com" is qualified - it doesn't matter if "example.com" exists in the wider DNS system, thats not even checked.

Sorry, but no.
Say you're on domain "foo.com" and connect to "myhost.example.com" and "myhost.example.company".
The former is a FQDN, but the latter is an unqualified address, which will (hopefully) take you to myhost.example.company.foo.com.

How do you propose the browser tell the difference between the two without asking a DNS server for SOA records?

Re:Easy fix

[DarkOx]

The trouble is the lusers have gotten used to thinking that 'foo.com' is the proper way to type an address, when they want 'foo.com.'. The browser can try foo.com and then its going to try foo.com.{something from my domain search suffice list}..

Re:Easy fix

[DavidRawling]

The trouble is the lusers have gotten used to thinking that 'foo.com' is the proper way to type an address, when they want 'foo.com.'. The browser can try foo.com and then its going to try foo.com.{something from my domain search suffice list}..

And this neatly demonstrates how the "domain escalation" approach would work for certificates.

When the browser is provided with https://foo/uri, it will use the configured DNS suffixes to find the server and then use the same DNS suffix to confirm that the connection should be trusted. So if you have mydomain.com. and mydomain.net. as your DNS suffixes, and foo resolves in mydomain.net., then the certificate must contain foo.mydomain.net. to be accepted.

Mind you I haven't programmed the sockets API so I don't know if it's possible to _get_ the list of DNS suffixes for a computer/connection/some other object. Maybe that's the sticking point?

Re:Easy fix

[arth1]

That would break domain hosting.
The same machine that hosts company1.com also hosts company2.net and company3.org

Of course, the web servers should be smarted and present, if present, a certificate that matches the Host: line in the HTTP request, and not have a static certificate.

Anyhow, back to the original post, yes, non-fully-qualified certificates are both legal and have their use. Consider a network that isn't Internet, with its own DNS root servers, for example. If a customer wants a certificate for "exchange", he should get it. He should also be flogged and fined if that cert is exposed to the internet.

Re:Easy fix

[Richy_T]

The certificate is used before the Host: header is sent. There are some fixes in the works for this.

Charge the CA with complicity in any attacks

[RichMan]

These are not names the CA should be issuing. The only reason for issuing them is greed.

Make the CA aware that should any illegal activity be done using unqualified names that the CA will held legally responsible.
Watch the unqualified names disappear overnight.

Re:Charge the CA with complicity in any attacks

[stevenbdjr]

Mod Parent Up.

Typically considerations for setting up an Exchange 2007 / 2010 CAS is to have a UCC cert that contains both the qualified and unqualified name of the CAS server (or CAS server array). This is to prevent Outlook from throwing a cert error when accessing the server internally.

While I can't speak to the security implications of such certificates, I can say that this is most certainly not something "controversial" that the SSL providers are doing, it's simply meeting a legitimate customer need.

Re:Charge the CA with complicity in any attacks

[Loether]

It is possible for an internal DNS server to resolve your mail.example.com to your local 10.x.x.x inside and let your external DNS tell the outside world the external address. If you are a very small shop and don't want to set up an internal dns server you could even just modify the host file on the boxes that need to access the internal servers.

Re:Charge the CA with complicity in any attacks

[Spad]

It's not actually an issue with 2010 any more as you should be specifying FQDNs for the RPCClientAccessServer values on your databases and Outlook will pull the necessary information out of AD when setting up new mail profiles.

Re:Charge the CA with complicity in any attacks

[jeffasselin]

Making a corporation legally responsible for its action is like striking at water with a sword. They'll pay the fine, and the executives will still swim in the money.

Re:Charge the CA with complicity in any attacks

[h4rr4r]

You're doing it wrong. This is not a legitimate need, this is folks doing it wrong.

Re:Charge the CA with complicity in any attacks

[TheRaven64]

Most browser have a set of criteria for certificate inclusion. One of these is typically an independent audit of their practices. I'd suggest that Mozilla should immediately drop all of these CAs, and require a $100,000 recertification if they wish to be included again. Their customers will then complain that, in between now and the time that they completed the recertification, all of their customers got scary warning messages. Gives a strong incentive for CAs not to do this kind of thing again.

Re:Charge the CA with complicity in any attacks

[guruevi]

Why not? If you set up your own CA you can issue any name you want as well, I can issue hotmail.com or fbi.gov. SSL certificates are NOT meant to identify a website, they are merely there to secure the link between a server and a client. When people (and browser makers) understand that, we will be quite a bit further.

Re:Charge the CA with complicity in any attacks

[Anonymous Coward]

Do all the teachers in your kids' schools always wear a condom when teaching?

Re:Charge the CA with complicity in any attacks

[sjames]

The problem is that the whole system was rigged to keep pointing back to "pay a CA for a cert".

In a system designed for security first, a server could easily have multiple identities, each supported by an independent cert (The web has finally grown that appendage in the form of SNI). The internal name of an exchange server would be backed by an internal Cert signed by the company's internal CA (with it's key installed on all employee machines) and the external name would be backed by a public cert signed by a generally recognized CA.

Of course, any cert would be usable to sign another cert so that example.com could use it's example.com cert (signed by a generally recognized CA) to sign their own cert for api2.example.com. Validation would be a matter of following the signatures until you get to a known and trusted cert. But we couldn''t allow that since it would conflict with "pay a CA for a cert" on the api2 site.

The tools to do all that would also be simpler without that policy. "gen-key --name whatever [other opts]", "sign-key thiskey --with thatkey", check-key. That's all that should have been required.

Re:Charge the CA with complicity in any attacks

[andymadigan]

"Your own CA" won't be trusted by browsers. SSL is intended to verify that when you create a connection to 'hotmail.com' the machine on the other end is in fact hotmail.com. Merely encrypting the connection does nothing if I can pretend to be hotmail.com and record your username/password.

The problem is that the browsers trust CAs which are unscrupulous.

Re:Charge the CA with complicity in any attacks

[Kalriath]

Of course, any cert would be usable to sign another cert so that example.com could use it's example.com cert (signed by a generally recognized CA) to sign their own cert for api2.example.com. Validation would be a matter of following the signatures until you get to a known and trusted cert. But we couldn''t allow that since it would conflict with "pay a CA for a cert" on the api2 site.

Uh, what? The reason that doesn't work is nothing to do with "pay a CA for a cert". The reason that doesn't work is that it would completely break the trust model. What you're suggesting would allow a criminal to obtain a certificate for dodgy-site.com (legitimately, since you believe CAs should not be allowed to verify identity and all that stuff because it's "just profiteering"), and use that to sign a cert for bankofamerica.com. Voila, instant MitM.

Essentially, your idea is foolish and ill conceived.

Re:Charge the CA with complicity in any attacks

[sjames]

The default level of trust would be the least trusted in the chain. Presumably, dodgy-site.com would be trusted only to sign subdomains of dodgy-site.com. That is, you trust that they really are dodgy-site.com because a CA you trust says so. That doesn't mean you believe they are conscientious enough to verify others identity for you. If you know and trust dodgy-site.com, feel free to make their cert a trusted introducer in your browser.

I never said CAs shouldn't be allowed to verify identity anywhere. The fact is, they too often don't, but they SHOULD.

If the CAs aren't a money grab, why does a wildcard cert cost more than a single name cert? If they are so conscientiously checking identities, why does TFA exist?

Re:Charge the CA with complicity in any attacks

[Anonymous Coward]

We are a *tiny* shop: three programmers. Setting up Bind9 took about 1 hour, once, and it's smooth sailing ever after. It's not like you need a special dedicated box or expensive software *just* for DNS.

I have a solution!!!!

[fuzzyfuzzyfungus]

Obviously, the notion that CAs are fundamentally broken, dubiously competent, and somewhat parasitic is bad for business and therefore can be rejected out of hand.

Therefore, I propose the following: All browsers shall be required to stop trusting those inexpensive standard SSL certs, as well as certs issued by budget CAs. 'Extended Validation' certs will now be baseline, with prices remaining unchanged, and two new levels of verification will be added:

'Extended Validation: Pinky Swear!'(indicated by a green background with two interlocking pinky fingers) will have the same standards as 'EV'; but with the additional promise that we had the work experience kid, or a script, whichever is cheaper, check that the certificate request wasn't made from a hotmail account.

'Double-Secret Extended Validation'(icon TBA, pending negotiations with film rightsholders) is so secure that we can't even tell you the process by which we verify applications; but it is super secure.

This should solve all CA related trust issues.

Re:I have a solution!!!!

[digitalchinky]

It's good you're not the boss of everything then :-) I would prefer that browsers simply accept self signed certs without any kind of warning at all - I just want the encrypted link without scaring away visitors.

Re:I have a solution!!!!

[yakatz]

All browsers shall be required to stop trusting those inexpensive standard SSL certs, as well as certs issued by budget CAs. 'Extended Validation' certs will now be baseline, with prices remaining unchanged, and two new levels of verification will be added:
'Extended Validation: Pinky Swear!'
'Double-Secret Extended Validation'
This should solve all CA related trust issues.

I read this an laughed, but then when I thought about it, you should not even suggest this kind of idea.
Making it more expensive to be secure is not a step in the right direction.

Re:I have a solution!!!!

[H0p313ss]

and two new levels of verification will be added: .... 'Extended Validation: Pinky Swear!' ... 'Double-Secret Extended Validation'

Well played sir.

Re:I have a solution!!!!

[snsh]

The major issue it would solve is trust in CA's by their shareholders that they will continue to earn profits.

Re:I have a solution!!!!

[DrXym]

I'd like to see self generated certs where the signature is a PGP key. Want to know if you can trust the cert? Look at the PGP web of trust. It should be quite feasible.

These kinds of certs would be more than adequate for individuals, small orgs and whatnot who want the security of a cert without paying a tax to a CA just so they can bless the cert with virtually worthless "trust".

I don't understand why the likes of Firefox / OpenSSL / GnuPG and other vested interests in the open source movement aren't pushing for a free model for certification which cuts the CAs out of the loop, at least for some kinds of certs.

Re:I have a solution!!!!

[ArsenneLupin]

I don't understand why the likes of Firefox / OpenSSL / GnuPG and other vested interests in the open source movement aren't pushing for a free model for certification which cuts the CAs out of the loop, at least for some kinds of certs.

Indeed. Especially since there is a free CA around: CaCERT.

Yes, they failed an audit. But the only reason why they failed it was that they were doing it honestly. Many other CAs which are currently accepted in Firefox would fail the same kind of audit, but they are smart enough not to submit to one.

Re:I have a solution!!!!

[ObsessiveMathsFreak]

Or how about we just give up with the idea of for profit third party authentication altogether and use either a handful of open authentication sites or just fall back on a distributed web of trust. I find the whole idea of founding our public key encryption systems on trusting a private, for-profit corporation to be laughable to begin with.

And the Mozillia/Firefox Debacle over self-signed certs would be funny right now if it wasn't so offensive.

Re:I have a solution!!!!

[DrXym]

CaCERT is a brave attempt to free up the web, but it's constrained by it's need to be seen as trustworthy in order to bestow trust. And in order to do that it has to force registrants to jump through hoops. In CaCERT's case if I want a cert I have to present my government papers to somebody in their web of trust. And I have to do it every 2 years. For what purpose?

The whole system also has a chilling effect on private communication with sites not using a cert who potentially could and should. I believe the easiest way to open up certification to all is to produce a class of certs between self signed and CA signed where the signature is a PGP web of trust. Nothing to stop CAs being signatories either (probably they sell such a service already), but in the absence of CAs my web of trust can be anyone I like and it's up to the visitor to decide if they consider the signatories trustworthy.

Re:I have a solution!!!!

[SmurfButcher Bob]

I don't see the problem. The existing process simply needs to require you to send something (by snailmail, email, or fax) on Company Letterhead.

Since "using fake letterhead to spoof a request to a CA" has recently been patented as a business method, the patent would stop any bad guys from requesting fake certs, and all your certs are now secure, again.

Re:I have a solution!!!!

[DarkOx]

Why?

I keep reading similar comments over and over again but I really want the use case is! I agree it does not make any sense for browsers to treat self signed certs as riskier than plain HTTP, but why use HTTPs without authentication.

Put another way, why worry who can see what your saying when you don't know who you are saying it to anyway?

I totally understand a self signed cert for say connecting to a private network you control and have the certificates for. A company installing a their private CA certs on company laptops to enable VPN or use of their extranet are great examples.

Really though give me one use case where its reasonable to what encryption with an unknown party.

Re:I have a solution!!!!

[heypete]

In CaCERT's case if I want a cert I have to present my government papers to somebody in their web of trust. And I have to do it every 2 years. For what purpose?

Actually, you need only show your identity documents to someone in their web of trust once. The identity validation is good "for life", and is associated with your cacert account. The certificates issued by cacert are valid for a maximum of two years, after which time one can get fresh certs (indeed, one can get certs revoked and new ones issued at any time).

Re:I have a solution!!!!

[locofungus]

Where you don't care about a determined attacker but want to stop a casual eavesdropper.

For example a blog where you want to require users to login. Stolen passwords are a pain but not a major issue but being able to stop people just sniffing them off unencrypted wifi connections makes sense.

Or want to stop ISPs seeing/hijacking pages to insert ads. Although ISPs could do a MITM attack on self signed certs, it's likely that before very long someone will notice an ISP doing it to one cert at which point people will very quickly see that it's happening to all of them.

Many (most?) SMTP servers will negotiate TLS with self signed (or non "official" CA signed certs) if it's available. It would be interesting to know how many email servers are setup to refuse to send if the cert cannot be verified. I'm sure there are some servers out there that do this (and they're probably only allowing manually installed CAs as well) but I expect they're few and far between.

Even between my home mail server that receives my mail and the backup mailserver I have if my home server is unavailable I forward using TLS (and the CA is installed) but I've not even considered bothering to block it if the certs don't match. If MI5 or the police decide they do want to intercept this mail then I probably wouldn't notice as the only visible symptom would be in the mailserver logs where it would no longer say the cert verified OK but someone at an ISP in the link is not going to accidentally start copying my mail traffic like google did with WIFI.

Tim.

Re:I have a solution!!!!

[Anonymous Coward]

Bad idea - but only about as bad as the way things are now. Nothing here would prevent a man in the middle from swapping in another self-signed cert and circumventing your encryption altogether. This would be invisible to clients who do not validate certificate fingerprints. The real problem is that we have gotten the incorrect idea in our heads that CAs can substitute for certificate validation.

Re:I have a solution!!!!

[AnyoneEB]

The reasoning is that the vast majority of the time, no one is doing a man-in-the-middle attack and furthermore that doing a man-in-the-middle attack on any significant proportion of the connections on the internet is assumed to be above the capabilities of any known attacker, so it means that you are probably talking to the owner of the DNS entry and normal passive sniffing attacks (ex. Firesheep) won't work. Also, the attacker may not be able to tell which connections are verified and which ones aren't (especially if the browser assumes self-signed sites will always use the same certificate until it expires), so even man-in-the-middle attacks on self-signed certs are non-trivial.

Also, the information being protected is generally assumed to be relatively low value, so protecting it with a relatively easy to break security layer is not a large problem: after all, it is currently being sent unencrypted.

Of course, hopefully verifying certificates via DNSSEC will be supported soon, which will make the entire self-signed certificates argument moot. (Err... well, eventually, once it is widely deployed.)

Re:I have a solution!!!!

[dkf]

just fall back on a distributed web of trust

Won't scale up, as it fails to take into account the fact that the world is full of idiots and assholes. Assholes will try to poison the trust web ("for great profit!") and idiots will act in ways that let the assholes do it without any way to get back at them.

The problem with the system of CAs is that nobody seems willing to pull the plug on crap ones. If CAs knew that they'd get kicked out of the magic money farm for screwing up, they'd take the right level of care. (Especially if they'd then have to fend off lawsuits from their erstwhile customers who suddenly find that their HTTPS sites don't work.) Nothing else is enough.

Re:I have a solution!!!!

[hairyfeet]

But that doesn't really matter as long as FF shows you that policeman with the giant GET ME OUT OF HERE! button like you just walked into a goat porn site, does it? When I went to their website and saw the FF policeman I just walked away because I knew that is EXACTLY what my customers would do.

And THAT is the real power of CAs and why them just throwing certs to anybody for anything is dangerous. The average Joe isn't gonna check details, he is just looking for the little policeman. If he sees the policeman he is outta there. I'd love for someone to use something like CaCERT and then check the pass through, I bet a good 80% of the average Joe users split when they spot the cop.

Re:I have a solution!!!!

[Anonymous Coward]

That renders SSL moot and suspecptable to MITM. No, the best bet is that browsers verify using DNSSEC. This will guarentee that the host you are talking to is the host registered in DNS for blah.example; the same level guarentee that the inexpensive SSL certs give.

(It might even be a better guarentee as DNSSEC should make revoke a certificate no different to any other DNS change.)

Re:I have a solution!!!!

[d1on1x]

It all comes down to weather or not the browser accepts it, and for now it looks like CaCERT is not valided yet. I tried https://www.cacert.org/ and Chrome shows that nice fancy red screen that tells me I am about to do something extremely dangerous, although if you read it it only tells me that they can't validate the owner, encryption is all fine .. .I wish they would make that more clear.

Wheres the data coming from?

[Richard_at_work]

Where are the EFFs SSL Observatory getting their data from, how well has it been validated? Their website only says "We have downloaded datasets of all of the publicly-visible SSL certificates on the IPv4 Internet" which doesn't say anything really - who is compiling this data and how are they doing it?

Re:Wheres the data coming from?

[fuzzyfuzzyfungus]

"For the technical research community, our source code as well as a MySQL database dump (August 2010 MySQL dump), the raw data (August 2010 raw data), and the August 2010 CSV database dump are available. You can also use the Observatory in an Amazon EC2 instance we created."

From the main page...

Re:Wheres the data coming from?

[Richard_at_work]

Uhm, yeah, thats the EFFs dataset and I saw that while writing my original post (yeah, I rtfa'd - someone does do it!)...

I'm talking about the origins of that data, where did it originally come from, how can they compile datasets of SSL certificates (which have no centralised point other than the CAs themselves - so are the CAs giving out information on cert signings?)

Re:Wheres the data coming from?

[fuzzyfuzzyfungus]

I assume that they crawled the web, looking for https:/// addresses and then scraped the information from those, since a given host attempting an SSL session will present the details of its cert and who signed it.

For their big-map-o'-CAs, it looks like the information you would need would be within available browsers, which by necessity come with a list of CAs that they trust, possibly with a bit of legwork to see if there are subordinate CAs involved...

Re:Wheres the data coming from?

[Richard_at_work]

That wouldn't give them certs signed for unqualified domains however, would it? They wouldn't be able to crawl the web for "localhost"...

Re:Wheres the data coming from?

[joostje]

you crawl https on mail.nonlocalhost.com, and discover it claims to be domain "mail", and present a cert for domain "main".

Re:Wheres the data coming from?

[tokul]

I don't think that LT CAs are trusted by Mozilla or Microsoft.

How about more simple analysis. Who signed those thousands of certs? Do we have to download 4GB of data just to see that?

Re:Wheres the data coming from?

[higuita]

they probably are doing something like the below script
please ignore the invalid IPs, localhosts, private ips, multicast, etc, this is just a quick script... a perl version would probably be faster and more intelligent :)

for a in {0..255} ; do
  for b in {0..255} ;do
    for c in {0..255} ; do
      for d in {0..255} ; do
          echo | openssl s_client -connect $a.$b.$c.$d :443 2>/dev/null | sed -n 's%0 s:.*/CN=\([^/]*\).*%\1%gp' > https.log
          echo | openssl s_client -starttls smtp -connect $a.$b.$c.$d :25 2>/dev/null | sed -n 's%0 s:.*/CN=\([^/]*\).*%\1%gp' >> smtp.log
          echo | openssl s_client -starttls imap -connect $a.$b.$c.$d :993 2>/dev/null | sed -n 's%0 s:.*/CN=\([^/]*\).*%\1%gp' >> imap.log
          echo | openssl s_client -starttls pop -connect $a.$b.$c.$d :995 2>/dev/null | sed -n 's%0 s:.*/CN=\([^/]*\).*%\1%gp' >> pop.log
          echo | openssl s_client -starttls ftp -connect $a.$b.$c.$d :21 2>/dev/null | sed -n 's%0 s:.*/CN=\([^/]*\).*%\1%gp' >> ftp.log
        done
      done
  done
done

it will take a few... weeks... months maybe, but it will return the SSL CN for all IPs
bugs: dont know how the wildcard certs will show up, doesn't show the certs alias and probably more bugs :)

Re:Wheres the data coming from?

[afidel]

I'm assuming they spidered the IPv4 address space looking for SSL connections and downloaded any certs they found.

Re:Wheres the data coming from?

[ArsenneLupin]

you crawl https on mail.nonlocalhost.com, and discover it claims to be domain "mail", and present a cert for domain "main".

That host doesn't listen on port 443 (https), and on port 993 (imaps), it uses a self-signed certificate for *.mail.dreamhost.com

Still very goofy, but not quite as bad as a certificate for mail signed by a "legitimate" CA.

Re:Wheres the data coming from?

[Anonymous Coward]

They crawled the whole IPv4 address space, and have done several talks about their findings. The talk they did at 27C3 is available for download and I certainly recommend watching it.

Info about the talk: http://events.ccc.de/congress/2010/Fahrplan/events/4121.en.html
Download Links: http://events.ccc.de/congress/2010/wiki/Conference_Recordings

What a coincidence

[GameboyRMH]

I was just working on a PC with a virus that routes all traffic through some sort of SSL MITM mechanism.

Surely that depends on what you name your mail ser

[djsmiley]

Our mailserver has a REAL fqdn.... mail.XXXXX.com. Its only ever refered to by this.... so how would having mail as a cert help? :/

WMDs issued to 1000's of highly unqualified beings

[Anonymous Coward]

seems as though being the 'man in the middle' there is all the rage? better days ahead. genuine native spirit prevails. babys rule now.

We knew this

[xnpu]

I'm sorry, but haven't most of us, in the back of our minds, known all along that the whole SSL thing is just a money scam?!

Even if the commercial CA's get there act together, there are still plenty of CA's that my browsers trust by default but are in fact highly suspect. SSL can provide real security, but not through public CA's that are blindly included in your browser/OS.

Re:We knew this

[samjam]

yes!
time to read this - definitions of trust
http://mcwg.org/mcg-mirror/trustdef.htm

no one types https

[Anonymous Coward]

how do signed certs really help anyway - step 1 for man in the middle is dns requests and no one is typing "https".

*.example.com should also be banned

[Relayman]

Generic certificates (like *.example.com) should also be banned in my opinion.

Re:*.example.com should also be banned

[Archangel Michael]

You're stupid and stupid should be banned.

Wildcard Certs are very handy. They aren't "generic" as you say, they are a specific kind of cert. We use them all the time, for nothing other than to get logins out of plain text on servers that don't really need to be "secure", so that people sitting in Starbucks can be safer from wifi session hacking when using those servers.

Wildcard Certs serve their purposes, and just because you don't know what those are, doesn't mean they are "stupid". It means you are the stupid one.

Re:*.example.com should also be banned

[Relayman]

Thanks for setting me straight.

Re:*.example.com should also be banned

[sqlrob]

Those aren't quite as generic as you think.

That covers a.example.com. It doesn't cover b.a.example.com

Re:*.example.com should also be banned

[Archangel Michael]

Sorry to be snarky. :-/

I come off like the ass I am sometimes.

Re:*.example.com should also be banned

[scrib]

I run a Really Small website that I'm trying to start up (and I'm not going to plug it, I'm weird like that). I don't really want to pay for an SSL cert since none of the data on the site is useful to hackers or criminals. The one exception is: passwords. The fact that people reuse passwords all over the place gives every website operator a great responsibility to protect passwords. Salts, modern hashes in the database, complexity requirements, all of it is moot if a MITM can just look at the raw login form data.

I WILL plug http://www.jcryption.org/ as a very nice way to do encryption for login forms. PHP generates the public key, sends it with the javascript in the form, all the form data is encrypted by the browser itself before sending it to the host.

Re:*.example.com should also be banned

[ArsenneLupin]

PHP generates the public key, sends it with the javascript in the form, all the form data is encrypted by the browser itself before sending it to the host.

And how do you protect against a man-in-the-middle changing the public key while it is being sent from PHP to the browser? Or against same middleman just adding some more javascript to the page which copies the sensitive form fields into new fields which will be transmitted in the clear (like happened in Tunisia with facebook...)?

Re:*.example.com should also be banned

[scrib]

Excellent question and good point. I guess I'm not really protecting against a true man-in-the-middle attack who has dedicated time and resources. It'll stop eavesdroppers, though. For now, and as long as my website isn't a money-maker and self-certified sites cause browsers to throw up frightening warnings, that will have to be good enough. I'll still suggest people don't use the same password on two sites.

Re:*.example.com should also be banned

[ArsenneLupin]

If your concern is the frightening warnings popped up by browsers, why don't you get a free certificate from startssl.com?

Startssl.com is recognized by all major browsers, checks your identity by a mail and phone callback, and issues as many "simple" certificates as you need. "Simple" meaning no wildcard, and no subject-alt-name. These are valid for one year

If you do need more advanced stuff (wildcard, subject-alt-name), you can have StartSSL do a more "thorough" id check. For this, upload a scan of two government-issued id documents, and send them $49.90 . They'll perform another phone check, and you're ready for "Class 2" certificates, which are valid for two years. You can still get as many as you want during validity of your id check (1 year).

You can't get cheaper than that (except for CaCert, but unfortunately CaCert is not recognized by the browsers by default).

The real problem are clients that accept that crap

[Anonymous Coward]

Why would a client accept an SSL certificate for an unqualified name? Even for internal networks and private CAs you should use qualified names.

No!

[Sloppy]

Make the CA aware that should any illegal activity be done using unqualified names that the CA will held legally responsible

A certification is a statement of opinion. (And furthermore, it is a statement by a complete stranger who has no relationship with you and owes you jack shit.) The sooner we learn this, the sooner we will start to work on real solutions to the problems (i.e. switch to OpenPGP). If you charge CAs with complicity, you are just legitimizing the flawed idea behind our current CA infrastructure and reinforcing the idea that certifications are some kind of sacrosanct objective statements of truth (or in this case, negligent or malicious statements of falsehood), yet that position is a complete denial of reality.

People treating CAs whom they have never personally met and have a relationship with, as fully trusted, is what has really failed here. In real life (as opposed to the internet fantasy) you can't fully trust a faceless CA's (Comodo, Verisign, whatever) statement that keyid xxx is so-and-so, any more than you can trust a stranger on the street to hold your wallet for an hour while you step away. Let's end the fantasy, instead of going to court and demanding that the delusion be continued to be given respect.

Re:No!

[BitZtream]

The funny part about your post is that you think PGP doesn't suffer from the exact same set of problems, AND a whole bunch of others that make it absolutely useless to normal people who don't want to be bothered with the fact that it was designed and meant to be used by a bunch of geeks trading keys.

You can't get through life if you trust no one, you'll die of starvation in your home. I have no urge to personally meet all the people I communicate with regularly in order to exchange keys, nor do I have any need/want to force hundreds of thousands of people using my websites to come visit me in person so we can exchange keys in order to do secure communications.

For that reason alone, CAs aren't going any where. I'm guessing you don't use any public key servers for PGP either since they are essentially accomplishing the same function as a CA without the actual identity verification part.

Re:No!

[firewrought]

Let's end the fantasy

Do you have something to replace it with? You can't end the CA fantasy just on rhetoric alone.

Re:No!

[ArsenneLupin]

A certification is a statement of opinion. (And furthermore, it is a statement by a complete stranger who has no relationship with you and owes you jack shit.)

The same can be said about passports and other government id papers. Does the border guard personally know the guy who issued you your passport? No? But yet he trusts it.

Re:No!

[Velex]

(And furthermore, it is a statement by a complete stranger who has no relationship with you and owes you jack shit.)

I know I'm going to get modded to hell for suggesting this, but why aren't governments in the business of issuing certs? Governments already issue DBAs and IDs, so why wouldn't it be ideal for them to issue the digital equivalent?

Re:No!

[Anonymous Coward]

Actually, some do.

http://www.id.ee/?id=28743&&langchange=1

Re:No!

[Sloppy]

The funny part about your post is that you think PGP doesn't suffer from the exact same set of problems

It doesn't suffer from the problem, because it's based on accepting the idea that you're never fully sure. That is how real life works. Some people are confident that their government never makes mistakes and issues ID to the wrong people, combined with a personal confidence that they are very good at spotting fake IDs. And some people aren't sure about both of those things at all, so they want to see two IDs. And in some redneck backwater, you damn well know there's someone who cares nothing about these IDs, and he'll tell you "we don't like strangers around here" simply based on whether or not he knows you, or maybe he'll make an exception if "..well, I ne'er seen you before, but Bubba here says you're his cousin who moved off to live with the city folks, so.. ok, I won't shoot you." OpenPGP can handle all this, depending on whatever it is that the user wants.

You can't get through life if you trust no one

No, you can't get through life if you never accept risk or if you fail to act whenever you are faced with ambiguity. X.509 ignores the whole topic of risk and distills it down to you either trusting a certification or not. It models 0% confidence and 100% confidence just fine, and yet these are almost never accurate measurements of the real situation.

I have no urge to personally meet all the people I communicate with regularly in order to exchange keys, nor do I have any need/want to force hundreds of thousands of people using my websites to come visit me in person so we can exchange keys in order to do secure communications.

You don't have to. If you trust Comodo, you can let Comodo do all that, just like you're doing with X.509 right now. What OpenPGP lets you do, is add on to that, have backup trust paths in place in parallel, should the day ever come that you alter your opinion about Comodo's trustworthiness or competence. And it lets you meet in person for any situations where that happens to be convenient, so that if you're ever talking to that person, instead of your browser telling you "this is probably who we think it is" it can say "we're almost completely sure."

X.509 has no concept of "probably" or "maybe" or "iffy" and yet that's something we need. When you're on a site that has only been identified to you by the Turkish intelligence service, it is astoundingly lame that with X.509 you can't have an encrypted connection without fully trusting the Turkish intelligence service. Dude, it is healthy to not trust the Turkish intelligence service; even if they're good guys and not out to get you (no need to be paranoid here), you probably don't know jack shit about them. They're nothing to you. That is the reality of the situation and your computer ought to be able to model it and represent it to you, instead of oversimplifying the way it does right now.

There needs to be a way to override this

[Anonymous Coward]

There should be a user configurable option in all browsers that you can point toward a standardized revocation list server.

Furthermore, you should be able to add more than one revocation list server in this option.

For example: You are running Chrome and it is pointing to the default revocation list on some one of google's servers. That is a nice corporate revocation list. It only has actually compromised certs on its list (which is good). However, I don't trust companies that have repeatedly issued bad certs. I want to execute the death penalty to whole CAs and even groups of CAs owned by the same company wholesale. I want to be able to maintain my own blackhole (to steal the term from email) list.

Personally, I would like to crosscheck my blackhole against all the companies who are listed by the EFF's observatory and blackhole all the companies that have had a violation of any kind.

I don't care if this leaves me with only 6 CAs left. THAT'S THE POINT. I want to get a message in my browser every time I hit a cert from a fishy company.

Theoretically, not a problem, but ...

[rich_salz]

This shouldn't be an issue, because the HTTPS rules say that the IPaddress must match, as well as the alternate names if present. Unfortunately, user's are convinced to tell their software to break the rules because PKI operations are handled so poorly.

Re:Theoretically, not a problem, but ...

[sid crimson]

I don't understand. When submitting for an SSL cert I don't recall ever providing an IP address. Praytell how does an SSL cert know that I am on the proper IP Address?

Re:Theoretically, not a problem, but ...

[Stray7Xi]

Domains are your identity on the web. IPs are your location. Certs verify identity of computer you're talking with, they don't need to contain IPs.

Worng

[Anonymous Coward]

Issuing a certification, is the essentially the same as notarizing something. So knowingly issuing a bogus certification should carry a similar similar penalty.

Certificate based security has lived

[McTickles]

In my humble opinion certificates have always been a shit idea, sorry but I think there are other ways to do security that don't involve bribing (huge amounts often) a so-called "Certification Authority" into creating a minuscule file (that you could have very easily made at home for FREE) to prove to others that you are nice.

This is just beyond ridiculous.

If they want to keep this fail system at the very least make certificates free and administered by a trustworthy and not-for-profit organization.

Re:Certificate based security has lived

[heypete]

"Huge amounts"? GoDaddy offers widely-trusted certs (their roots are in all major browsers, and also chain back to the old ValiCert root so it works with ancient browsers) for about $13/year. Hardly "huge amounts".

StartSSL has their root in all major browsers, and they issue certs for free. (Naturally, they also offer Class 2 and EV certs for money, but their basic domain-validated certs are free.) While the PKI model has its flaws, StartSSL seems to be doing The Right Thing within the confines of the model (4096-bit roots, 2048-bit minimum key length, checks for weak keys, no internal/unqualified names, etc.).

Re:Certificate based security has lived

[McTickles]

Sorry but given GoDaddy's abysmal reputation and their tendency to pull outrageous stunts on their customers I do not think they qualify to be trusted with anything.

Who cares if their "roots" are in all major browsers... I bet any dictator on earth could convince browsers to have their roots doesn't make them any more trustworthy.

Im surprised that following the news about Comodo that company still has the guts to sell certificates.

The point is, the sale of certificates is a very profitable racket, a small script to generate certificates, a high price tag (considering the amount of work performed manually, NONE), this is even worse than fees on bank transactions (which are also just scripts).
Hell, if I believed that this is in anyway ethical I would have a CA set up in a few minutes with a couple lines of scripting, but sadly I believe it is a fraudulent system, as the recent news have demonstrated.

The current CA-based system needs to change.

"webmail" where I work

[GeekDork]

It would be immediately obvious when someone performed a MitM attack using a valid certificate for "webmail". Why? Because the real certificate is signed by a ghetto CA that isn't trusted by any of the "major" vendors, and both the certificate and some of the intermediates have long since expired.

I'll be worried if I can access that site without a bunch of ugly warnings popping up.

Re:"webmail" where I work

[Xacid]

Rofl. So true, so true.

Is there a problem?

[WaffleMonster]

The global CA infustructure is used for a lot more than just securing public web sites.

To understand if there is even a problem you first need to check the key usage/EKUs of these certs to see in what context the certificates are allowed to be used.

Re:Is there a problem?

[ArsenneLupin]

To understand if there is even a problem you first need to check the key usage/EKUs of these certs to see in what context the certificates are allowed to be used.

Do browsers check these key usage/EKUs? If not, these certificates could still be used for nefarious purposes, even if such usage is against some paper document somewhere...

And if yes, I'd think EFF would have raised less of a fuss...

Re:Is there a problem?

[VortexCortex]

The global CA infustructure is used for a lot more than just securing public web sites.

To understand if there is even a problem you first need to check the key usage/EKUs of these certs to see in what context the certificates are allowed to be used.

The global CA "infustructure" (sic), used in any scenario, fails to ensure the trust is certified, absolutely.

It's down-right broken, should be abandoned IMMEDIATELY!!!.

Wait! Before you mod me troll or skip past this thinking I'm a nut-job, ask yourself this: Does a "valid" cert PROVE that the domain named in the cert actually requested the cert be made? Well, does it?

NO. It does not!

A "valid" cert only proves that a "trusted" authority has signed the certificate. A "valid" cert in no way ensures that the "trusted" authority actually had the permission of the domain owner to issue the certificate.

This system can therefore not be trusted AT ALL.

The main problem is two-fold: 1) DNS is unsecure. 2) People want to charge extra for a damn public / private key chain -- a cert.

I propose, as part of DNS registration, the domain owner must create a public / private key pair and register their public key.

All requests for SSL certificates must then also be either:
1) signed FIRST by the private key of the domain owner, or...
2) done away with completely as an obsolete technology -- The domain's registered public key can be used.

The point is this: Time and time again we find that starting with a 100% unsecured system, then adding in layers of security is a faulty, insecure design. Eg: Some MS OSes, firewalls that are fully open except "bad" ports, email SPAM (no sender verification required, no end to SPAM in sight), the list goes on...

We're starting out with an unsecured network, then adding in security layers on top -- WTF? Why not just require, that after a period of adjustment has passed, all DNS & Internent packets be encrypted by the domain owner's private/public key pair? The routers don't have to be upgraded to support this -- they still just pass along the bits, but the end points can then be secured.

FTFWA DNSSEC

While protecting IP addresses is the immediate concern for many users, DNSSEC can protect other information such as general-purpose cryptographic certificates stored in CERT records in the DNS. RFC 4398 describes how to distribute these certificates, including those for email, making it possible to use DNSSEC as a worldwide public key infrastructure for email.

Bang: No more spam. Bang: no more SSL certs that weren't requested by the domain owner. Bang: no more SSL certs for unqualified names on the Internet (INTRAnet is a different matter -- set you devices to trust whatever you want, as always).

TFA is just another nail in the coffin for unsecured DNS & the whole untrustable SSL CA security theater.

Re:Is there a problem?

[VortexCortex]

Excuse the self reply, but a colleague pointed out an interesting point: "Securing Everything means no caching"

Interesting, yes, but totally incorrect. Data that is to be cached can be signed instead of obfuscated via encryption, thus yielding security AND caching capabilities. Web browsers currently warn that a page contains both secure (encrypted) and unsecure (non encrypted) items. If a third option of, "signed but not encrypted", were available, the page could would no-longer contain both secure and insecure items -- Hell, all of my GIT commits use this type of security already...

Re:The real problem are clients that accept that c

[BitZtream]

Because entering 'mail' in my client is far less annoying than mail.hq.internal.mydomain.com, and it has the added benefit that if I make an image that talks to mail rather than mail.hq.internal.mydomain.com it can be deployed at any other site and still function correctly. So an image made on hq.internal.mydomain.com also works on nyc.internal.mydomain.com and lax.internal.mydomain.com without any additional work.

Re:The real problem are clients that accept that c

[ArsenneLupin]

In order for 'mail' to work, somebody had to set up your DNS with a "search path" of "hq.internal.mydomain.com". Why can't whatever software is connecting to 'mail' also append the search path to the hostname used for checking the certificate?

It's Microsoft's fault

[Anonymous Coward]

I bet most of those are to get stupid f*ing MS Exchange 2007 to authenticate itself on a LAN.