×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Thousands of SSL Certs Issued To Unqualified Names

CmdrTaco posted about 3 years ago | from the oh-that'll-be-fine-i'm-sure dept.

Electronic Frontier Foundation 128

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!'"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

128 comments

No news here (1)

energizer-bunny2 (1308043) | about 3 years ago | (#35732258)

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 (5, Informative)

6031769 (829845) | about 3 years ago | (#35732328)

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 (1)

energizer-bunny2 (1308043) | about 3 years ago | (#35732392)

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 (1)

Spad (470073) | about 3 years ago | (#35732518)

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

Re:No news here (2)

energizer-bunny2 (1308043) | about 3 years ago | (#35732550)

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 (2)

Spad (470073) | about 3 years ago | (#35732652)

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 (2)

bsDaemon (87307) | about 3 years ago | (#35732730)

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 (0)

Anonymous Coward | about 3 years ago | (#35733826)

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 (1)

Amouth (879122) | about 3 years ago | (#35736438)

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 (2)

kasperd (592156) | about 3 years ago | (#35733508)

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 (0)

Anonymous Coward | about 3 years ago | (#35732742)

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 (2)

h4rr4r (612664) | about 3 years ago | (#35732790)

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 (0)

Anonymous Coward | about 3 years ago | (#35732916)

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

Re:No news here (1)

h4rr4r (612664) | about 3 years ago | (#35733496)

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

Note, that was sarcasm.

Re:No news here (2)

energizer-bunny2 (1308043) | about 3 years ago | (#35735016)

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 (4, Informative)

cbiltcliffe (186293) | about 3 years ago | (#35736116)

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 (0)

Anonymous Coward | about 3 years ago | (#35732800)

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

Re:No news here (1)

repetty (260322) | about 3 years ago | (#35733466)

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 (1)

fishbowl (7759) | about 3 years ago | (#35733730)

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 (3, Interesting)

BitZtream (692029) | about 3 years ago | (#35733926)

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 (1)

snsh (968808) | about 3 years ago | (#35732414)

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 (1)

Anonymous Coward | about 3 years ago | (#35732590)

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 (4, Informative)

TheRaven64 (641858) | about 3 years ago | (#35733006)

.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 (2)

kasperd (592156) | about 3 years ago | (#35733454)

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

Easy fix (1)

Anonymous Coward | about 3 years ago | (#35732266)

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

Re:Easy fix (1)

Richard_at_work (517087) | about 3 years ago | (#35732398)

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

Re:Easy fix (1)

eggled (1135799) | about 3 years ago | (#35732572)

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 (1)

Richard_at_work (517087) | about 3 years ago | (#35732644)

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 (1)

eggled (1135799) | about 3 years ago | (#35732778)

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 (1)

Richard_at_work (517087) | about 3 years ago | (#35732904)

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 (1)

arth1 (260657) | about 3 years ago | (#35734152)

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 (1)

DarkOx (621550) | about 3 years ago | (#35734662)

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

Charge the CA with complicity in any attacks (4, Interesting)

RichMan (8097) | about 3 years ago | (#35732290)

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 (1)

stevenbdjr (539653) | about 3 years ago | (#35732330)

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 (1)

Loether (769074) | about 3 years ago | (#35732410)

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 (1)

Spad (470073) | about 3 years ago | (#35732580)

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 (1)

h4rr4r (612664) | about 3 years ago | (#35732824)

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 (0)

Anonymous Coward | about 3 years ago | (#35734832)

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

Re:Charge the CA with complicity in any attacks (2)

jeffasselin (566598) | about 3 years ago | (#35732736)

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.

No! (2)

Sloppy (14984) | about 3 years ago | (#35732858)

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.

Worng (0)

Anonymous Coward | about 3 years ago | (#35733136)

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

Re:No! (1)

BitZtream (692029) | about 3 years ago | (#35734780)

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! (1)

firewrought (36952) | about 3 years ago | (#35734956)

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! (1)

ArsenneLupin (766289) | about 3 years ago | (#35736124)

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! (1)

Velex (120469) | about 3 years ago | (#35737012)

(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! (0)

Anonymous Coward | about 3 years ago | (#35737080)

Actually, some do.

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

Re:Charge the CA with complicity in any attacks (1)

TheRaven64 (641858) | about 3 years ago | (#35733090)

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 (1)

guruevi (827432) | about 3 years ago | (#35734066)

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.

I have a solution!!!! (5, Funny)

fuzzyfuzzyfungus (1223518) | about 3 years ago | (#35732340)

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!!!! (2)

digitalchinky (650880) | about 3 years ago | (#35732460)

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!!!! (1)

DrXym (126579) | about 3 years ago | (#35732764)

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!!!! (1)

ArsenneLupin (766289) | about 3 years ago | (#35732926)

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 [cacert.org].

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!!!! (1)

DrXym (126579) | about 3 years ago | (#35734258)

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!!!! (1)

heypete (60671) | about 3 years ago | (#35734836)

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!!!! (1)

DarkOx (621550) | about 3 years ago | (#35734400)

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!!!! (3, Informative)

locofungus (179280) | about 3 years ago | (#35734906)

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!!!! (2)

AnyoneEB (574727) | about 3 years ago | (#35735306)

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!!!! (0)

Anonymous Coward | about 3 years ago | (#35734916)

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!!!! (1)

yakatz (1176317) | about 3 years ago | (#35732554)

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!!!! (1)

H0p313ss (811249) | about 3 years ago | (#35732562)

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!!!! (1)

snsh (968808) | about 3 years ago | (#35732660)

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!!!! (1)

ObsessiveMathsFreak (773371) | about 3 years ago | (#35733154)

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!!!! (1)

SmurfButcher Bob (313810) | about 3 years ago | (#35734358)

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.

Wheres the data coming from? (2)

Richard_at_work (517087) | about 3 years ago | (#35732342)

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? (4, Informative)

fuzzyfuzzyfungus (1223518) | about 3 years ago | (#35732390)

"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 [eff.org]...

Re:Wheres the data coming from? (1)

Richard_at_work (517087) | about 3 years ago | (#35732556)

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? (1)

fuzzyfuzzyfungus (1223518) | about 3 years ago | (#35732846)

I assume that they crawled the web, looking for https:/// [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? (1)

Richard_at_work (517087) | about 3 years ago | (#35733018)

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? (2)

joostje (126457) | about 3 years ago | (#35733224)

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? (1)

ArsenneLupin (766289) | about 3 years ago | (#35736172)

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? (1)

higuita (129722) | about 3 years ago | (#35734890)

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? (1)

afidel (530433) | about 3 years ago | (#35735540)

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? (1)

tokul (682258) | about 3 years ago | (#35734472)

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?

What a coincidence (1)

GameboyRMH (1153867) | about 3 years ago | (#35732356)

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 (1)

djsmiley (752149) | about 3 years ago | (#35732488)

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 (0)

Anonymous Coward | about 3 years ago | (#35732762)

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 (1)

xnpu (963139) | about 3 years ago | (#35732788)

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.

no one types https (0)

Anonymous Coward | about 3 years ago | (#35732808)

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 (1)

Relayman (1068986) | about 3 years ago | (#35732838)

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

Re:*.example.com should also be banned (1)

Archangel Michael (180766) | about 3 years ago | (#35733378)

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 (1)

scrib (1277042) | about 3 years ago | (#35735000)

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/ [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 (1)

ArsenneLupin (766289) | about 3 years ago | (#35736360)

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 (1)

sqlrob (173498) | about 3 years ago | (#35734170)

Those aren't quite as generic as you think.

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

The real problem are clients that accept that crap (0)

Anonymous Coward | about 3 years ago | (#35732848)

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

Re:The real problem are clients that accept that c (1)

BitZtream (692029) | about 3 years ago | (#35734922)

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 (1)

ArsenneLupin (766289) | about 3 years ago | (#35736418)

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?

There needs to be a way to override this (1)

Anonymous Coward | about 3 years ago | (#35732940)

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 ... (1)

rich_salz (612602) | about 3 years ago | (#35732962)

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 ... (1)

sid crimson (46823) | about 3 years ago | (#35733196)

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?

Certificate based security has lived (1)

McTickles (1812316) | about 3 years ago | (#35733338)

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 (1)

heypete (60671) | about 3 years ago | (#35734980)

"Huge amounts"? GoDaddy offers widely-trusted certs [godaddy.com] (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 [startssl.com] 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.).

"webmail" where I work (1)

GeekDork (194851) | about 3 years ago | (#35734408)

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.

Is there a problem? (1)

WaffleMonster (969671) | about 3 years ago | (#35734454)

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.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...