Beta
×

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!

SSL Cert Weaknesses Exposed By Comodo Breach

timothy posted more than 3 years ago | from the well-he-showed-me-his-badge dept.

Security 194

snydeq writes "InfoWorld's Woody Leonhard delves deeper into the Comodo SSL scandal and finds the breach calls into question the integrity of the SSL certification process itself. 'While the press has focused on the sensational fact that Comodo's site was hacked from an Iranian IP address, we really should be asking three questions: How did somebody working with an Iranian IP address get a username and password from Comodo with enough clearance to create SSL certificates? Why did Comodo issue SSL certificates for google.com, live.com, yahoo.com, mozilla.org, and skype.com? Why are browser updates used to revoke SSL certificates?'"

cancel ×

194 comments

Sorry! There are no comments related to the filter you selected.

Even more important (-1)

Anonymous Coward | more than 3 years ago | (#35609390)

Why does Slashdot's comment system still suck donkey balls?

Where did those entry-level "designers" get the idea that a button labeled "Get 234 more comments" should instead just fetch 50 comments? And why is it placed at the bottom of the page when it loads comments in threads all over the page?

To preload a complete discussion you have to mindlessly jump to the bottom of the page, fetch 50 comments, jump to the bottom, fetch 50 more ad nauseum.

Visit a user interface guidline course you fucking dumbasses.

Re:Even more important (1)

Psychotria (953670) | more than 3 years ago | (#35609402)

Well, you could just create an account and get them all at once; it's not that difficult is it?

Re:Even more important (1)

Jesus_666 (702802) | more than 3 years ago | (#35609534)

To be honest, it's still annoying for regular users who just happen to visit from work during their lunch break. Yes, I could log n every time and diligently check the "public terminal" checkbox but I don't really see why.

Of course what's more annoying is that the RSS feed is now apparently run by Twitter and only shows the first ~100 characters of each featured post, making it pointless to even load them in the first place. The "get more comments" thing can be circumvented by logging in; this can't.

Re:Even more important (3, Interesting)

TheRaven64 (641858) | more than 3 years ago | (#35609994)

How? I have an account, and I've clicked on the load all comments button in preferences, but I still only get 250 comments by default. Other complaints:

  • It's still a fixed-width layout, so I have scroll bars unless I make my browser window wider (what is this, 1998?)
  • In a recent update, some event handler when I reply to a comment in the page that opens when I jump to a specific comment (e.g. in a message) decides to jump me back to the top of the thread and makes the input text field lose focus

Re:Even more important (2)

Inda (580031) | more than 3 years ago | (#35610140)

It all sucks dog's balls.

Using the old D1 system is the only usable option.

http://slashdot.org/prefs/d1

can't see the forest for the fallout? insecure? (-1)

Anonymous Coward | more than 3 years ago | (#35609398)

as populations, there's lots we can do. as bill nye guy individual armchair physicysts & enviroMENTALists (&/or nazi media based decepticons/mindless bots), we excel, even using the fake math, & 0 facts, so that's good? belittled/disempowered? we allow that/do it to ourselves. did we mention the newer bips show ability to digest crude oil with sometimes less than fatal results? they're fully aware of radiation/photons etc.... their eyesight (nothing like we're familiar with) incorporates bird like (magnetic fractal reasoning) navigation (meeting the need), & they are adapting to the unavoidable increase in available solar power/light.-- wee key (diaper) leaks group, perishability & play-dates pending. lots of other stuff in the works, pending disarmament (weapons media georgia stone) etc...

mynutwon; security is not the problem? (0)

Anonymous Coward | more than 3 years ago | (#35609462)

excessive insecurity aka FEAR rankles through the topically challenged /.monologue, & everywhere else now?

simple goals yet mentioned anywhere;

disarmament

ground up(before we end up that way) intervention/disassembly of our secret ruler based military industrial complex.

public intervention in our fear/propaganda/adv.++++/censorship/fear based media mogulism.-- wee key (diaper) leaks group, perishability & play-dates pending

birth certificates being flushed down commodes (0)

Anonymous Coward | more than 3 years ago | (#35609632)

burned, shredded? just paper? & that's by far not the worst of it. get/keep your eye on 'the ball' if you want to make a hit. seems to work. once the wholesale killing stops, we'll see things improve.-- wee key (diaper) leaks group, perishability & play-dates pending.

babys rule worldwide. play ball.

HMS lollipop going down, rats, minions debarking (0)

Anonymous Coward | more than 3 years ago | (#35609700)

the aggression/killing will likely increase as the last-gasper self-worshipping neogods use ALL (wmd/media/propaganda) of the last of their only abilities.

our gratitude to those who've given their lives/wellbeing up for us so far. we know you can feel it. some of us are a little slow. we're getting it. looks like about the 7th inning of this fixed race. thanks.-- wee key (diaper) leaks group, perishability & play-dates pending

Thanks Comodo (2)

Mr_Plattz (1589701) | more than 3 years ago | (#35609400)

Before those questions are answered, I'd just like to thank Comodo for making my next SSL certification renewal an even easier decision.

Re:Thanks Comodo (5, Informative)

thue (121682) | more than 3 years ago | (#35609796)

The beauty of it is that even if you do not buy your certificate from Comodo, you are still just as vulnerable to false certificates in your name from Comodo (Or any other of the ~650 CAs [eff.org] ).

Re:Thanks Comodo (1)

Nos. (179609) | more than 3 years ago | (#35610676)

There was a posting somewhere... SANS I think, that raised a good point.

We know that Comodo had a breach, they went public about it, they revoked the certificates in a reasonable timeframe, and generally followed best practices with regards to the breach.

How many others would do that?

So the Iranians.... (0)

Anonymous Coward | more than 3 years ago | (#35609406)

Stuxed it back to the world ;)

Punish Comodo (0)

Anonymous Coward | more than 3 years ago | (#35609412)

I have deleted all the Comodos certs from my browser. I dont't want to trust them.

Regarding question 1 (-1, Troll)

Mouldy (1322581) | more than 3 years ago | (#35609420)

Why the hell shouldn't someone from Iran be able to buy a SSL certificate? Seriously. Racist summary much.

Re:Regarding question 1 (1)

spottedkangaroo (451692) | more than 3 years ago | (#35609440)

Ahh, I don't think it says iranians shouldn't be able to get ssl certs. I think it says they shouldn't be able to get ssl certs for google.com, live.com, yahoo.com, and mozilla ... Seems logical to me that this would be a problem since they're american companies. Drop nearly any country in for iranian and you have the same exact question.

Re:Regarding question 1 (2)

Confusador (1783468) | more than 3 years ago | (#35609460)

Conversely, someone with a North American IP shouldn't be able to get a cert for the National Iranian Oil Co. [www.nioc.ir] , at least not without triggering a sanity check in the system. I can't see why that would be controversial; clearly someone wasn't doing their job.

Re:Regarding question 1 (0)

Anonymous Coward | more than 3 years ago | (#35609592)

So "bit.ly" which is used all over twitter should be controlled by Colonel Gaddafi, yes? It is the country code for Libya after all.

Re:Regarding question 1 (1)

Confusador (1783468) | more than 3 years ago | (#35609654)

My contention had to do with the country of organization of the company and the country of origination of the request, nothing to do with the domain, so your question is off topic. (We're talking about CAs, not ICANN) But yes, when Col Gaddafi was undisputedly the legitimate head of Libya, his government should have had control of the .ly TLD. They're welcome to sell domains to anyone they like, Libyan or not, but I always thought American companies were crazy to use them.

Re:Regarding question 1 (1)

spottedkangaroo (451692) | more than 3 years ago | (#35611090)

I'm just saying what the article said. Really, the question isn't that it was an iranian IP, although that certainly seems suspicious to me since there likely isn't a functioning legal system there; the question is, how can someone get a certificate for google.com if they aren't in fact an agent of google.com. To check this properly requires human intervention and so CV certs cost a minimum of $1000 ... There's really no way aroudn this though.

Re:Regarding question 1 (0)

Anonymous Coward | more than 3 years ago | (#35609452)

Why the hell shouldn't someone from Iran be able to buy a SSL certificate? Seriously. Racist summary much.

The assumption is that it's an uncommon thing in Iran, which it is. Also, "Iranian" is not a race.

Re:Regarding question 1 (-1)

Sique (173459) | more than 3 years ago | (#35609482)

Sorry to correct you, and completely offtopic, but "Iran" means "land of the Aryans", and an "Iranian" is just "Aryan".
Please be careful with the words.

Re:Regarding question 1 (1)

Nursie (632944) | more than 3 years ago | (#35609542)

Except many Iranians would identify as 'Persian', not Aryan, and dissociate the race from the country.

Re:Regarding question 1 (1)

Anonymous Coward | more than 3 years ago | (#35609872)

That's the dumbest thing I've ever heard. The derivation of a country name does not determine the ethnicity of the people born in that country. By your logic a Persian born in Iran is not Iranian? Either that or you would claim that a Persian born in Iran is not Persian but Aryan?

Re:Regarding question 1 (1)

Hazel Bergeron (2015538) | more than 3 years ago | (#35611130)

I don't mean to butt in like some pre-political-correctness oaf to this learned inquiry on pedigree, but "Aryanian" sounds really cool. Can we use that word somewhere in your argument?

Re:Regarding question 1 (-1)

Anonymous Coward | more than 3 years ago | (#35609456)

Cuz Iran should be nuked off the map by israel

Re:Regarding question 1 (1)

zandeez (1917156) | more than 3 years ago | (#35609464)

Isn't Iran on the US Blacklist for crypto exports? It's not racist, the US do impose such bans on countries they don't like.

Re:Regarding question 1 (4, Informative)

flonker (526111) | more than 3 years ago | (#35609468)

They didn't buy it. They created it through the reseller process. OpenSRS, for example, requires that all IPs that have access to the domain registration process are registered beforehand. That would have stopped this attack cold. Comodo didn't even have so much as a "wow, that's funny, this /24 has never logged in before, and is registered to a country I don't have any resellers in." Also, a lot of people seem to believe that automated systems should blacklist high profile targets from being automatically granted certificates.

Re:Regarding question 1 (1)

gnasher719 (869701) | more than 3 years ago | (#35609690)

Why the hell shouldn't someone from Iran be able to buy a SSL certificate? Seriously. Racist summary much.

Nobody except Google should be able to buy an SSL certificate for www.google.com. Whether Google resides in Iran or not shouldn't make a difference, and whether that somebody who isn't Google resides in Iran or not shouldn't make a difference either.

On the other hand, trying to buy a certificate for a US company when you are not even from the USA is just a tiny little hint that something might not be quite right here. Just like trying to buy a certificate for an Iranian company when you are not from Iran is just a tiny little hint that something might not be quite right.

Re:Regarding question 1 (1)

Anonymous Coward | more than 3 years ago | (#35609794)

OMFG.... discrimination on national origin is NOT fucking 'racist'. "Racism" is discrimination based on RACE--caucasian, negroid, etc. While sorting out people because they (or their ancestors) hail from Iran (or Ireland or Iceland) is indeed a "discrimination" (and that word itself is not necessarily a negative connotation)---IT IS NOT RACISM!

Jesus people, actually learn the terms before you sling them around. You wanna complain that someone is being exclusionist based on national origin? At least label them with the right exclusion. "Racist summary much" is kneejerk reaction from someone more interested in promulgating kneejerk reactions than in understanding and responding to the issue.

SSL certs are both over-trusted and under-trusted (5, Insightful)

billyswong (1858858) | more than 3 years ago | (#35609446)

If you went to a site with a cert signed by those big companies, those sites are trusted with no questions. If a site don't want to pay and use a self-signed cert instead? Wow, the end-user are warned as if it is more dangerous than plain HTTP site!

A more rational mechanism should be telling users the truth honestly, i.e. "this site's traffic is encrypted and the authority is promised by xxx.com, or if self-signed, self-proclaimed". Those big companies aren't that trustful, they are just lucky enough to gain an early seat into the root cert trust list in the dawn of internet.

Re:SSL certs are both over-trusted and under-trust (2)

arogier (1250960) | more than 3 years ago | (#35609470)

If only we weren't beholden to decisions made in the 80's and 90's. IPv4, HTTPS we might as well start over. While we're at it hardware AES extensions on more low power processors, should I really have to choose between a VIA Nano and Core i5 if I want decent SSL encoding speed.

Re:SSL certs are both over-trusted and under-trust (1)

arogier (1250960) | more than 3 years ago | (#35609496)

Also the Certs have too much trust and the protocol itself too little.

Re:SSL certs are both over-trusted and under-trust (2)

TheSunborn (68004) | more than 3 years ago | (#35609490)

The problem with that solution, is that it give no protection against "man in the middle" attack.

Re:SSL certs are both over-trusted and under-trust (2)

billyswong (1858858) | more than 3 years ago | (#35609538)

The problem with that solution, is that it give no protection against "man in the middle" attack.

Please elaborate, as I have not suggested any changes in the protocol (yet). I am merely asking browsers to present things more accurately, closer to the truth, not "see the little lock then you are safe" stuff. Also not over-reactive to outdated/self-signed cert.

Re:SSL certs are both over-trusted and under-trust (2)

Nursie (632944) | more than 3 years ago | (#35609556)

You would have self-signed certs presented as "semi-secure", which they are not.

Re:SSL certs are both over-trusted and under-trust (-1)

Anonymous Coward | more than 3 years ago | (#35609610)

https with self signed cert is more secure than plain http

Re:SSL certs are both over-trusted and under-trust (2)

Nursie (632944) | more than 3 years ago | (#35609630)

Only if the client has the certificate ahead of time. Otherwise it really isn't.

Re:SSL certs are both over-trusted and under-trust (0)

Anonymous Coward | more than 3 years ago | (#35609660)

https with self signed cert protects against passive eavesdropping, plain http does not

Re:SSL certs are both over-trusted and under-trust (2)

HungryHobo (1314109) | more than 3 years ago | (#35609664)

I accepted a self signed cert from a college server when I was physically in the room with it and chances of MITM were stunningly low.

I go home and get a change of cert warning connecting to the server and alarm bells start ringing.

In such a case self signed certs are *more* secure than a cert signed by someone...somewhere who is apparently trusted by someone has signed their cert and which may have been compromised as in TFA.

Re:SSL certs are both over-trusted and under-trust (2)

muckracer (1204794) | more than 3 years ago | (#35609742)

> Only if the client has the [self] certificate ahead of time. Otherwise it
> really isn't [more secure than plain http]

Actually all you need is the fingerprint of the certificate to verify, not the whole cert.

For example, as hosting provider you may provide PHPMyAdmin logins for your customers, so they can admin their databases from the browser. A self-signed certificate from the hosting provider to secure that login is perfectly reasonable, as is a phone call to the customer providing them with the fingerprint of the self-signed cert to prevent a MITM. And yes, that is most certainly more secure than plain-text HTTP. In fact, it's even more secure than the gazillion-trusted-potentially-MITM-enabling CA certs!

Re:SSL certs are both over-trusted and under-trust (0)

Anonymous Coward | more than 3 years ago | (#35609768)

It's a false sense of security unless you trust the certificate authority that issued the certificate. I could have intercepted your traffic, generated my own self-signed certificate for the web site you're going to and masquerade as that site and you have no way of verifying if I am lying or not unless you already have their certificate in your trusted certificate list or you trust the certificate authority that issued it. Both of those would mean acquiring the certificate of the site and/or the certificate authority via some trusted out-of-band method prior to the communications with the web site.

Re:SSL certs are both over-trusted and under-trust (1)

grahamm (8844) | more than 3 years ago | (#35610060)

Yes, you have to trust the certificate authority, but the same applies to the many CAs which are accepted by default by the (major) browsers. How have these many CAs demonstrated to 'Joe Sixpack' user that he should trust them?

Re:SSL certs are both over-trusted and under-trust (0)

Anonymous Coward | more than 3 years ago | (#35610704)

You would have self-signed certs presented as "semi-secure", which they are not.

They are perfectly secure for certain scenarios. If I visit site A and it presents a self-signed cert, and I come back the next day, I know that it's the same site. I also know all transmissions were encrypted. I know that no one who wasn't listening before is listening now.

And small organizations can use them quite effectively. I can call someone on the phone and read out the damned cert fingerprint. I can even put the cert on a thumbdrive and copy it to a laptop.

Re:SSL certs are both over-trusted and under-trust (0)

Anonymous Coward | more than 3 years ago | (#35611056)

I think he would have them presented as equally secure as vanilla HTTP, which they are.

Re:SSL certs are both over-trusted and under-trust (1)

TheSunborn (68004) | more than 3 years ago | (#35609682)

The problem is that anyone can create a self signed cert to your site.

Imagine that you use a self signed certificate on yourdomain.com

When a user then connect the first time and is presented with the cert, that user have no way to know if the cert he see is greated by you, or created by someone claiming to be you.

Remember: Anyone can create a self signed certificate to google.com

Re:SSL certs are both over-trusted and under-trust (4, Informative)

Confusador (1783468) | more than 3 years ago | (#35609918)

But it's still better than http, because it's not trying to solve the vulnerability you're complaining about. Plain HTTP is vulnerable to MITM and ANY SORT OF EAVESDROPPING. Self signed certs are vulnerable to MITM, and eavesdropping (I believe) if the 3rd party catches all of the key exchange. CA signed certs are vulnerable to neither.

Claiming that self-signed certs are the same as plain-old-http is as ridiculous as claiming that self-signed certs are secure. They won't protect you against an even mildly determined attacker, but they will stop e.g. the Google van from picking up your email. (Yes, that would have been a problem users could have fixed easily, but do you trust them? More layers of security, when easily implemented, are better.)

Re:SSL certs are both over-trusted and under-trust (1)

mwvdlee (775178) | more than 3 years ago | (#35609974)

Basically, HTTP is vulnerable to absolutely everything, uncertified HTTPS is vulnerable to almost everything.

Re:SSL certs are both over-trusted and under-trust (1)

AdamsGuitar (1171413) | more than 3 years ago | (#35610720)

HTTPS is vulnerable to MITM when using a self-signed certificate, but not eavesdropping. The encryption used for the key exchange (RSA) is not made any more or less secure by the CA that issued the certificate; CA's are there to prevent MITM by establishing trust.

Re:SSL certs are both over-trusted and under-trust (1)

Anonymous Coward | more than 3 years ago | (#35611242)

But it's still better than http...

No, it is not: a false sense of security is worse than no sense of security at all.

Serisouly, how can any /.'er not know this?

Browser designers have it right: the only thing between a succesful and a failed mitma is the user realising that the certificate is self-signed. "the user" meaning "any user". Think about the "any" part.

Re:SSL certs are both over-trusted and under-trust (0)

Anonymous Coward | more than 3 years ago | (#35609922)

You can always import your self-signing CA.crt into browser or simply write down cert. fingerprints!

Re:SSL certs are both over-trusted and under-trust (0)

Anonymous Coward | more than 3 years ago | (#35609686)

You get encryption without authentication, which is worthless - think about it this way : A user coming to your site is told "Trust me because I am who I say I am!" - Anybody could say that - even somebody who is not you. With a web of trust, a user goes to somebody who they already trust (A root CA) to verify you are who you say you are. You cannot send authentication - it must already be present.

Re:SSL certs are both over-trusted and under-trust (2)

Jon Stone (1961380) | more than 3 years ago | (#35609692)

With unencrypted HTTP, any one who can see the packets can snoop the whole session.

With SSL/TLS, with a self-signed certificate, the attacker has to be in a position to tamper with the packets. The attacker has to impersonate the server to the client, and potentially the client to the server (depending on the attack). This is a much harder problem than simply sniffing the traffic with tcpdump.

Anyone on a public WiFi network can sniff the packets of other users on the WiFi network. It would be very difficult to pull off an attack on a self-signed SSL connection.

Re:SSL certs are both over-trusted and under-trust (1)

igb (28052) | more than 3 years ago | (#35609898)

It wouldn't be trivial to pull off an attack on a self-signed SSL connection, but it's not hard. On a public wifi system (the scenario you're proposing) it's trivial to fake DNS responses faster than the real responder. The attacker then just presents a different self-signed certificate, using the same DN for the subject and the issuer as the target system. The fingerprint will be different, which may or may not trigger a warning, but the warning will be the same as it was when the self-signed cert was initially presented. This will fool 90% of the people 90% of the time.

If techie people want to secure their personal infrastructure, the solution is to operate their own CA, with appropriate precautions around the signing key, and install the root key for that into their personal systems. That's somewhat harder to attack. Somewhat. Other good things to do include "always VPN into some known better systems" and "use IPSec and/or DNSSEC on your resolver queries". Certificates are something of a last-ditch defence, though, because by the time your TCP connections are being terminated by the attack you've already lost quite a lot of assurance.

Re:SSL certs are both over-trusted and under-trust (1)

Jon Stone (1961380) | more than 3 years ago | (#35610180)

All you can ever do is make the attack harder/riskier/more expensive. Self-signed certificates make a trivial attack harder. Tracking what certificates a site used and warning if it has changed (the same approach openssh uses), gives almost all the benefit the CAs give. Yes some users will ignore the warnings, but they'll also ignore the warnings about expired certificates, certificates with the wrong commonName, etc. As this story shows, the CAs themselves are far from perfect and often don't live up to being called "trusted third parties".

I wouldn't trust my financial information to a connection using a new, never seen before, self-signed certificate, however they do introduce security benefits over plain HTTP. The fact that self-signed certificates lead to Firefox to issue scary warnings when unencrypted connections don't is ridiculous.

Re:SSL certs are both over-trusted and under-trust (1)

grahamm (8844) | more than 3 years ago | (#35611274)

I wouldn't trust my financial information to a connection using a new, never seen before, self-signed certificate, however they do introduce security benefits over plain HTTP. The fact that self-signed certificates lead to Firefox to issue scary warnings when unencrypted connections don't is ridiculous.

What would be better for financial institutions would be if they did self-sign, or run their own CA, and present the CA certificate to customers over the counter in the branch when the account is opened and have it available, on demand over the counter, for anyone to collect. ie promulgate the certificate using an out-of-band mechanism which gives some measure of assurance to the customer.

Re:SSL certs are both over-trusted and under-trust (1)

asdf7890 (1518587) | more than 3 years ago | (#35610358)

It might be harder right now, as you can't just open up firesheep or similar and have it do the work for you, but as soon as someone releases a proof of concept attack that works via arp poisoning you can bet your last penny that script kiddies all over the world will be running the hack.

Given there are free certs with proper trust paths available that are accepted by the vast majority of browsers (http://en.wikipedia.org/wiki/Startssl#StartSSL is the only one I know of, but there may be others) there is no need for self-signed certs on public facing sites at all.

Re:SSL certs are both over-trusted and under-trust (1)

Jon Stone (1961380) | more than 3 years ago | (#35611148)

dsniff [monkey.org] was released over 10 years ago and does what you suggest. OpenSSH still works fine using the equivalent of self-signed certificates.

A number of ISPs seem to think that snooping on their customers' traffic for things like Phorm is acceptable. How many of them would think they could get away with forging SSL certificates? On every connection their customers make?

I've never said self-signed certificates are perfect, only that they do offer benefits over unencrypted connections. What benefit does a StartSSL certificate have over a self-signed certificate when accessing a random web forum run by someone I've never heard of? So what if StartSSL assures me it's run by someone called Joe Bloggs, why do I care? What security does it buy me over and above a self-signed certificate? How about compared to the self-signed certificate my browser stored when I initially signed up to Joe Bloggs' forum?

open access points (2)

leuk_he (194174) | more than 3 years ago | (#35609980)

obfuscated http [wikipedia.org] (https without certificates) is way more secure against wiretapping than not security at all.

And even then the current GUI of browser for invalid https certificates is way less usefule than expected. Due to the harsh error it is not a good strategy to hack out comodo yourself, since you get a lot of error messages that are not important.

https does only garantee there is no man in the middle attack. the CA does not say much more than that. Even a malware ridden site for a company "always trust" might get a certificate. It might even be untrackable after that.

Re:SSL certs are both over-trusted and under-trust (1)

DarkOx (621550) | more than 3 years ago | (#35610290)

This is the real source of trouble, failure to identify the bigger threat. Man in the middle attacks are a problem but they are not the more serious risk to defend against.

In order to execute a MITM attack I need to be able to manipulate your routing, dns, or both. Generally such and attack will be therefore limited to a finite number of people.

The more common attack is phishing! I can get hundreds of CC numbers etc with a successful phishing scheme. So the real value of SSL is identification. Solid identification of the remote party is more important most of the time then encryption. Which is not say the encryption is not important but I would rather put energy is stronger ID validation first

Re:SSL certs are both over-trusted and under-trust (3, Informative)

Rigrig (922033) | more than 3 years ago | (#35609696)

I agree it's stupid how browsers show self-signed certificates as more dangerous than plain HTTP.

The difference between paid-for certificates and self-signed certificates means more than just who promises authenticity though: The certificate's signature can be checked against the certificate shipped with the browser, thus preventing MITM attacks.

Basically:

  1. HTTP: everybody on the network can read your stuff, including passwords etc. They don't even need to perform a MITM attack. With a simply MITM attack they can also alter content.
  2. Self-signed HTTPS: your traffic isn't that easily sniffable anymore, but an attacker can perform a MITM attack to read/alter your data. He'd intercept all your browsers' requests, including the certificate, and replace them with his own.
  3. CA-signed HTTPS: an attacker can't perform a MITM attack, because intercepting the certificate request means it's signature won't match with the CA-cert that your browser shipped with.

Thus paid-for certificates mean you won't get MITM'd, the part where the CA also verifies identities is just bonus.

Re:SSL certs are both over-trusted and under-trust (0)

Anonymous Coward | more than 3 years ago | (#35609738)

MITM attacks on HTTPS and SSH have been fairly trivial within at the least the white community for years. Do some googling. All you gain from a CA-cert is auto trust on most browsers. Most who are familiar with these protocols argue that once the client has accepted and saved self-signed, you are better off. A change in the cert results is a huge client error stop-the-world error. Where as when a CA-cert changes from one to another you can't tell the difference without going through N (usually >2) dialog boxes.

Re:SSL certs are both over-trusted and under-trust (0)

Anonymous Coward | more than 3 years ago | (#35609808)

Thus paid-for certificates mean you won't get MITM'd, the part where the CA also verifies identities is just bonus.

You must not be paying attention to the current article; CA-signed certs are only better if the CA is trustworthy. This story is a case where MitM with fully-validated CA-signed certs were possible/probable because the CA didn't act in a trustworthy manner...

Re:SSL certs are both over-trusted and under-trust (1, Insightful)

kangsterizer (1698322) | more than 3 years ago | (#35609762)

It is more dangerous when self-signed. Because it gives you a false sense of security otherwise. On plain http you _know_ you are not secure.
On self-signed you _think_ you are secure so you'll put your credit card number and what not more easily, while in fact, maybe you're not secure.

Note: self-signed is not necessary unsecure, you just need to make sure you know what you trust when you click "ok and save" the first time.. or get the cert separately and make the same checks.

Not if you do it right. (1)

Kludge (13653) | more than 3 years ago | (#35610594)

It is more dangerous when self-signed. Because it gives you a false sense of security otherwise.

It only gives you a false sense of security if the browser tells you should have a sense of security. If the browser does not say that the connection is authenticated, then you get no sense that it is authenticated.
If you have an encrypted but not authenticated session, then the browser should just display the web page, without the little lock icon, like it does with plain html. It should NOT put up a prompt trying to scare people away from the web page and making them click through 4 different buttons like stupid-ass "Firefox" does. Talk about stupid!

On plain http you _know_ you are not secure.

No, most people are not that smart. Most people log into their accounts using plain http from open wireless access points. If you asked most people, they would not know the difference.

Re:SSL certs are both over-trusted and under-trust (1)

m50d (797211) | more than 3 years ago | (#35610890)

It's only more dangerous if you think it isn't. Browsers could display self-signed sites as if they were unencrypted; that would be better than the current situation, and no more dangerous.

Re:SSL certs are both over-trusted and under-trust (1)

Timmmm (636430) | more than 3 years ago | (#35609868)

Easy solution: Store self-signed certificate in DNS, access it using DNSSEC.

Re:SSL certs are both over-trusted and under-trust (1)

ObsessiveMathsFreak (773371) | more than 3 years ago | (#35609914)

A more rational mechanism should be ...

This isn't about rationality. This is about the people who run and implement SSL being pig-headedly stuck in their ways, refusing to permit any other system except their own, and being in chronic denial about existing problems with that system.

If you want a better encryption and/or authentication system for http traffic, you're going to have to code your own.

Re:SSL certs are both over-trusted and under-trust (1)

itsdapead (734413) | more than 3 years ago | (#35609920)

Wow, the end-user are warned as if it is more dangerous than plain HTTP site!

Yes, a self-signed https connection can be more dangerous than a plain http one if you see the "https" or the "golden padlock" and assume you have a secure connection.

You're confusing a specific tool (encryption) with the job (a browser establishing that a connection is sufficiently secure to justify displaying the "golden padlock" that non-technical users are told to look for before they enter their credit card details).

To do the job properly the browser needs encryption and some way of confirming the identity of the remote site. In the general case, encryption alone is not secure.

You may have a specific application in which you judge encryption alone to be sufficient (e.g. setting up a login for your blog so you can remember user preferences) but for other applications it is inadequate (you wouldn't log in to an e-banking site if it used a self-signed certificate, would you?) Plus, if you are a webmaster, even if you are capable of making that distinction yourself, you don't have the right to decide, on behalf of all your users, that they should trust you.

Now, the certificate-signing system is a million miles from perfect (as TFA shows) and its probably the weakest link in https, but identity verification and "trust chains" are always going to be much messier than pure encryption, and its the best we have and/or that people are prepared to put up with. "Encryption + certificate signed by a trusted authority" is the "least worst" criteria we currently have for telling a non-technical user that their connection is "secure".

A more rational mechanism should be telling users the truth honestly, i.e. "this site's traffic is encrypted and the authority is promised by xxx.com, or if self-signed, self-proclaimed"

Let's translate that message into how a typical browser user would understand it:

"This site's tetrion beam is modulated by an inverse tachyon pulse created by reversing the polarity of the neutron flow in the Heisenberg compensator. Abort/Retry/Ignore?"

...and from that, is supposed to decide whether they can safely type in their credit card number? Of course not - the best you can hope for is to educate them to "look for the secure connection icon". In that case, the only responsible advice that a browser can give about an unsigned certificate is "don't trust this site unless you understand the risks".

Re:SSL certs are both over-trusted and under-trust (1)

mwvdlee (775178) | more than 3 years ago | (#35610002)

Yes, a self-signed https connection can be more dangerous than a plain http one if you see the "https" or the "golden padlock" and assume you have a secure connection.

So this issue is not a technical but a social one.
Technically, self-signed HTTPS is more secure than plain HTTP, but only by a small margin.
But it could be percieved to be much more secure than it actually is.
So, why not visually display both self-signed HTTPS and HTTP the same, instead of marking one in bright red?
Then change the padlock with an open door for HTTP, a close door for self-signed HTTPS and a packlocked door for certified HTTPS?
Currently self-signed HTTPS is visually presented to the user as less secure than HTTP, which it isn't.

Re:SSL certs are both over-trusted and under-trust (1)

itsdapead (734413) | more than 3 years ago | (#35611302)

So this issue is not a technical but a social one.

Unless you see technology as a self-justifying end in itself, rather than as a tool to solve real-world problems (which often have social dimensions) that's not a useful distinction. Technology is pointless unless it accounts for the social dimensions.

Technically, self-signed HTTPS is more secure than plain HTTP, but only by a small margin.

In certain circumstances (e.g. a major bank or e-commerce site which could be a juicy enough target to attract sophisticated attacks) HTTPS with a self-signed certificate is actively suspicious and warrants a warning. Your browser can't distinguish these from circumstances in which encryption alone is adequate.

HTTP is just plain insecure, and there shouldn't be any expectation of security. Also bear in mind that some (most?) browsers do, by default, warn you if you submit a form over a plain HTTP connection (although everybody then clicks "don't show this message again" - a true nanny society wouldn't give you that option, but you have to draw the line somewhere).

...and on a practical level, most current HTTPS sites (a) do have a trusted certificate and (b) use HTTPS specifically because they are going to collect some sensitive information, so "HTTPS without trust" is a fairly sensible threshold to start warning people without drowning them in warnings.

So, why not visually display both self-signed HTTPS and HTTP the same, instead of marking one in bright red?

Because some people will think "https means secure, right?" and need to be actively warned when it is not.

Then change the padlock with an open door for HTTP, a close door for self-signed HTTPS and a packlocked door for certified HTTPS?

That violates "keep it simple, stupid". You're still designing for someone like you, who knows and cares about the distinctions, rather than a random user.

The best message for random users is still "don't use self-signed https sites unless you understand the risk".

Contact your browser vendor (or submit a patch) (0)

Anonymous Coward | more than 3 years ago | (#35610962)

If CA certs could be trusted only for given top-level domains, this breach wouldn't have occurred!

In that case, a European CA wouldn't have been trusted for a .com address.

Peter Guttman's take (4, Informative)

kensan (682362) | more than 3 years ago | (#35609458)

He makes some interesting points on EFF's SSL Observatory mailinglist: https://mail1.eff.org/pipermail/observatory/2011-March/000138.html [eff.org]

Re:Peter Guttman's take (3, Insightful)

Jesus_666 (702802) | more than 3 years ago | (#35609662)

Let me get this straight.

If I have the ability to obtain a cert for one site (say, mycompany.com), I have the ability to obtain entirely valid certs for any site on Earth? And the only way to counteract this is to have browser vendors blacklist my keys in their next update? And that's the foundation HTTPS stands on? And alternative schemes that may address the problem aren't even considered by the browser vendors?

Wow. If I understand that correctly, web encryption is in a pretty bad shape as far as trustworthiness goes.

Re:Peter Guttman's take (1)

icebraining (1313345) | more than 3 years ago | (#35610756)

I don't think you can generate them yourself, I think what he's saying is that many CAs don't check if you're the owner of the domain before issuing the cert to you.

The way to counteract it should be by dropping all CAs that don't follow a rigorous verification procedure before issuing certs from the browsers default trusted cert list; of course that raises different problems, like what happens to the thousands of websites that have certs issued by those CAs.

Re:Peter Guttman's take (2)

lbschenkel (751547) | more than 3 years ago | (#35610784)

Not exactly. But if you manage to compromise or convince any of the built-in CAs trusted by browsers (or any of the hundreds -- or thousands -- of sub-CAs they delegate to) to give you a certificate for any website on Earth, and you can redirect your victims to go to your website instead of the real one, then yes. By compromising any CA where you can build a chain of trust to a trusted root, then you can impersonate any website (if you manage to get a certificate). Some of these CAs are actually owned/controlled by some not-so-trustful governments, and they can generate any certificate they want. Quite a weak weakest link, don't you think?

Re:Peter Guttman's take (1)

lbschenkel (751547) | more than 3 years ago | (#35610876)

Oops. I meant trustworthy, not trustful.

There really is no proof the hackers are from Iran (2, Interesting)

Anonymous Coward | more than 3 years ago | (#35609476)

All we have is Comodo claiming they were from Iran, and an IP address. But why should we trust them? If you ask me, Iran fits in a bit too well as the bad guys.

Re:There really is no proof the hackers are from I (0)

Anonymous Coward | more than 3 years ago | (#35609622)

Agreed...hell, they could have used Tor! https://blog.torproject.org/blog/detecting-certificate-authority-compromises-and-web-browser-collusion

Re:There really is no proof the hackers are from I (2)

flak89 (809703) | more than 3 years ago | (#35609740)

This is stupid many time there is a story about hacking and a IP coming from that 'third world country' (insert name here China[ ], Iran [x], Russia [ ], all other[ ]......), someone assume that a person local to that country did all the job. What if that IP in Iran was not secured ? What if that person actually used the internet and connected to that IP in Iran from somewhere else (doh). There is a ton of non-patched OS, vulnerable IP out there. Some peoples shouldn't use the internet (or for that matter shouldn't make conclusions or assumptions on 'too technical stuff')

Re:There really is no proof the hackers are from I (0)

Anonymous Coward | more than 3 years ago | (#35610014)

It always amuses me when russia and china are referred to as "third world". How can people remain so ignorant when they have the internet at their fingertips?

Re:There really is no proof the hackers are from I (1)

mwvdlee (775178) | more than 3 years ago | (#35610044)

Good point.

If you were to use a hacked IP address to do something evil, would you do it using an IP address in a friendly country who'd gladly help the victim's country to track you down or would you go through an IP address in a country that hates the victim's country. Every little bit helps when it comes to security.

Two more questions (5, Insightful)

Lincolnshire Poacher (1205798) | more than 3 years ago | (#35609812)

1. Why was a key-gen server connected to the Internet? Shouldn't certificates be delivered out-of-band, such as on a CD delivered to the indicated registered address?

2. Why exactly do we still trust Comodo as a CA, when the like of cacert.org [cacert.org] cannot meet the "requirements" to be added as a CA in Mozilla products?

Re:Two more questions (3, Insightful)

RulerOf (975607) | more than 3 years ago | (#35610966)

Why exactly do we still trust Comodo as a CA, when the like of cacert.org [cacert.org] cannot meet the "requirements" to be added as a CA in Mozilla products?

$urely, you can't be $eriou$.

Re:Two more questions (0)

Anonymous Coward | more than 3 years ago | (#35611024)

1. Why was a key-gen server connected to the Internet? Shouldn't certificates be delivered out-of-band, such as on a CD delivered to the indicated registered address?

Have you ever used SSL before? Certs are emailed to you.

Re:Two more questions (1)

YodasEvilTwin (2014446) | more than 3 years ago | (#35611404)

He's saying they SHOULDN'T be emailed. WOOSH

WebTrust Ca certifications (1)

nereid666 (533498) | more than 3 years ago | (#35609854)

To be a CA is a serious thing it requires to have some certifications: Comodo CA Ltd is a commercial CA based in the UK and serving customers worldwide.
Audit: WebTrust CA, performed by Ernst and Young: Audit Report and Management's Assertions
Audit: WebTrust EV, performed by Ernst and Young: Audit Report and Management's Assertions

http://www.mozilla.org/projects/security/certs/pending/#Comodo

Do I have to trust Comodo?

Do I have to trust WebTrust certifications?

Do I have to trust Ernst and Young?

some thoughts (1)

muckracer (1204794) | more than 3 years ago | (#35609864)

I, for one, am grateful that this incident happened and the bad state of affairs gains publicity. Let's not forget, this has been possible for years and chances are extremely high, that it's been exploited by various Stasi's already....except nobody's really been noticing it.

As far as I am concerned, the SSL CA model was really a DOA. Except with the 1990's gold rush of "e-commerce" nobody cared for anything but the quick and dirty solution. Which is, what we're still stuck with. Hardcoding "trust" is so foreign to how the world in general and people in particular work, that it's not even funny in its ridiculousness.
While I don't have ideal solutions either, I imagine, that real trust can only be established by tying domain certificates to actual people. Think GPG-style WOT. Think specifically Lawrence E. Page (CEO, Co-Founder and President, Products), Eric Schmidt (Executive Chairman) and Sergey M. Brin (Co-Founder and President, Technology) signing GPG-style Google's master key. Each company, depending on size, would then be their own CA and chances are, they have better control over what certs get created for which of their domains.
Yes, signatures too can be forged as can the keys to create them with. But this is where the WOT would lend itself to. Even if they hate each other, Google master keys and Microsoft's could be cross-signed. Win-Win for both companies. And tied to real people (CEO's, CTO's etc.). Combine that with something like Perspectives (that too could be crowd-sourced!), DNSSEC, and SSH-style key-saving on first connect (also accomplished with the Certificate Patrol FF plugin), and you can completely get rid of the useless, expensive and insecure CA model.

Re:some thoughts (1)

VGPowerlord (621254) | more than 3 years ago | (#35610588)

While I don't have ideal solutions either, I imagine, that real trust can only be established by tying domain certificates to actual people. Think GPG-style WOT. Think specifically Lawrence E. Page (CEO, Co-Founder and President, Products), Eric Schmidt (Executive Chairman) and Sergey M. Brin (Co-Founder and President, Technology) signing GPG-style Google's master key. Each company, depending on size, would then be their own CA and chances are, they have better control over what certs get created for which of their domains.
Yes, signatures too can be forged as can the keys to create them with. But this is where the WOT would lend itself to. Even if they hate each other, Google master keys and Microsoft's could be cross-signed. Win-Win for both companies. And tied to real people (CEO's, CTO's etc.). Combine that with something like Perspectives (that too could be crowd-sourced!), DNSSEC, and SSH-style key-saving on first connect (also accomplished with the Certificate Patrol FF plugin), and you can completely get rid of the useless, expensive and insecure CA model.

What happens when, say, Eric Schmidt leaves Google [slashdot.org] ?

This isn't some hypothetical situation either, as Eric Schmidt has already left Google. His successor as CEO is Larry Page, Google's other founder.

Re:some thoughts (1)

muckracer (1204794) | more than 3 years ago | (#35611540)

> What happens when, say, Eric Schmidt leaves Google?

Well, Eric Smith doesn't stop being Eric Smith and Google is still, well, Google. The signature is, for the time being, still valid since it says nothing except "This key really belongs to Google Inc. Sincerely, Eric Smith".
The key would then be updated by having the new CEO sign it. A mechanism to put a time limit on signatures may also be useful (akin to having the option of having keys expire at some point).

We buy certificates on behalf of our customers (1)

rainer_d (115765) | more than 3 years ago | (#35609902)

Maybe a couple of dozens per year.
If something goes wrong, e.g. there's a mismatch in names on the csr with what is in whois, all sorts of problems arise.
The chaos in the processes is just mind-boggling sometimes.

I'm glad we have our own CA and can self-sign.

As said, these companies have just been lucky enough to be in the right spot at the right time to have their root-CAs int the browsers.
Interestingly, at least Microsoft has a page detailing the requirements for the CA, should it wish to be part of that list:
http://technet.microsoft.com/en-us/library/cc751157.aspx [microsoft.com]

How does it work for Firefox?

Responsibility and Liability (0)

Anonymous Coward | more than 3 years ago | (#35609972)

Shouldn't Comodo be liable for any damage done with these certificates? They obviously didn't do their job, which is making sure that the identity of the person requesting the signature matches the certificate. Preventing exactly the kind of problem we're seeing is their only raison d'etre!

What? Oh, Comodo. (1)

mooingyak (720677) | more than 3 years ago | (#35610034)

First time through I read that as "SSL Cert Weaknesses Exposed by Commando Breach"

Re:What? Oh, Comodo. (0)

Anonymous Coward | more than 3 years ago | (#35610114)

Better than my first read of a "commode" (as used in hospitals/nursing homes) breach.

More importantly... (1)

hesaigo999ca (786966) | more than 3 years ago | (#35610084)

Isn't Comodo a AV software company, I thought there were very few companies that truly had the power to hand on SSL certs. or I guess I am wrong, verisign, no? If any company can start handing out certs, especially to big companies that are public on the stock exchange, so that such a move could affect stock prices, I would say a better regulation needs to be in play....maybe there could be some
international action on this, not some lone company (like comodo) that has access to such important security issues.

Re:More importantly... (1)

Machtyn (759119) | more than 3 years ago | (#35610604)

Actually, Comodo is a certificates company. Their free firewall and, later, AV product was always just an afterthought for them. It wasn't until just the past couple of years that Comodo has allocated resources (with subscription service) for users of their Internet security software.

Re:More importantly... (1)

Slashdot Parent (995749) | more than 3 years ago | (#35611402)

I thought there were very few companies that truly had the power to hand on SSL certs. or I guess I am wrong

Open up your browser's configuration options and look at all of the root certs. I didn't count mine, but it looks like there are a several hundred entities that can issue trusted certs. Whether or not that qualifies as "very few" depends on what you would consider to be a large vs. small number.

SSL = Fail. (0)

Anonymous Coward | more than 3 years ago | (#35610692)

As the corporate IT Guy who has had to deal with SSL certs for a good portion of my career, I have to say that the entire state of the SSL certification process is a joke. In fact, Windows 7 doesn't even ship with more than the absolute bare minimum of root authorities. This is a problem since those authorities are necessary for all installed browsers save Firefox (which segregates its cert store from the Windows store). Most of the bargain-basement certificates (and, subsequently, the only affordable certs for small businesses with tight budgets) are reliant on an intermediate certificate back to a root store. If that root store isn't there, then the whole chain breaks.

On top of that, Microsoft is responsible for periodically updating their certificate revocation list, as well as providing updated root certificates. And they're terrible at it. I've frequently run into issues where one intermediate certificate will break this whole process and effectively freeze all certificate updates. On top of that, if you're not getting those updates, the only certs out there that will validate in any browser using the Windows cert store are Verisign and a couple others that ship with Windows.

Verisign is owned by Symantec, of course, so if you want to get on that bandwagon, you need to shell out nearly two thousand dollars. And that's just for the lowest level certificate. If you don't, you run the risk of your users freaking out because their browser thinks that GoDaddy or DigiCert certificate you bought for a hundred bucks is bogus. Ultimately, the perceived security of your site is based upon the quality of the system updates your users are getting, and that's not the sort of thing most of in the IT world are comfortable with. I suppose there is a reason why most of the well known eCommerce vendors out there are using Verisign.

What's most ridiculous is how widely the price range varies from one vendor to another. All for essentially the same product.

ip security and ipv6 (1)

reasterling (1942300) | more than 3 years ago | (#35611234)

wouldn't this be a non issue if we had ipv6 with ip security setup?
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?