Slashdot Mirror
SSL Cert Weaknesses Exposed By Comodo Breach
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?'"
Before those questions are answered, I'd just like to thank Comodo for making my next SSL certification renewal an even easier decision.
Well, you could just create an account and get them all at once; it's not that difficult is it?
Stuxed it back to the world ;)
I have deleted all the Comodos certs from my browser. I dont't want to trust them.
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.
Imagine if you weren't allowed to use roads because a bus company complained about your driving 3 times. --skunkpussy
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.
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.
He makes some interesting points on EFF's SSL Observatory mailinglist: https://mail1.eff.org/pipermail/observatory/2011-March/000138.html
Conversely, someone with a North American IP shouldn't be able to get a cert for the National Iranian Oil Co., 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.
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
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.
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.
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.
http://www.aaronrogier.net
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.
The problem with that solution, is that it give no protection against "man in the middle" attack.
See: http://en.wikipedia.org/wiki/Export_of_cryptography_in_the_United_States#Current_status and http://en.wikipedia.org/wiki/Rogue_states (Yes, I know wikipedia sources...)
Also the Certs have too much trust and the protocol itself too little.
http://www.aaronrogier.net
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.
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
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.
Except many Iranians would identify as 'Persian', not Aryan, and dissociate the race from the country.
You would have self-signed certs presented as "semi-secure", which they are not.
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.
Agreed...hell, they could have used Tor! https://blog.torproject.org/blog/detecting-certificate-authority-compromises-and-web-browser-collusion
Only if the client has the certificate ahead of time. Otherwise it really isn't.
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.
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.
https with self signed cert protects against passive eavesdropping, plain http does not
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.
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
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.
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.
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.
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:
Thus paid-for certificates mean you won't get MITM'd, the part where the CA also verifies identities is just bonus.
**TODO** [X] Steal someone elses sig.
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
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.
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')
> 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!
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.
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.
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.
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...
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 cannot meet the "requirements" to be added as a CA in Mozilla products?
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?
Damia
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.
Easy solution: Store self-signed certificate in DNS, access it using DNSSEC.
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?
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.
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
How does it work for Firefox?
Windows 2000 - from the guys who brought us edlin
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.
May the Maths Be with you!
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.)
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".
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
You can always import your self-signing CA.crt into browser or simply write down cert. fingerprints!
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!
Basically, HTTP is vulnerable to absolutely everything, uncertified HTTPS is vulnerable to almost everything.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
obfuscated http(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.
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:
I am TheRaven on Soylent News
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.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
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?
First time through I read that as "SSL Cert Weaknesses Exposed by Commando Breach"
William of Ockham had no beard. The most likely explanation is that it was chewed off by squirrels every morning.
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.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
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?
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.
Better than my first read of a "commode" (as used in hospitals/nursing homes) breach.
It all sucks dog's balls.
Using the old D1 system is the only usable option.
http://slashdot.org/prefs/d1
This post contains benzene, nitrosamines, formaldehyde and hydrogen cyanide.
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.
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
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
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.
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.
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.
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.
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.
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.
I am trolling
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.
I think he would have them presented as equally secure as vanilla HTTP, which they are.
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.
Imagine if you weren't allowed to use roads because a bus company complained about your driving 3 times. --skunkpussy
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?
dsniff 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?
wouldn't this be a non issue if we had ipv6 with ip security setup?
"For I desired mercy, and not sacrifice" -- God
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.
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.
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".
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
With a comodo signed cert? Forever? I dont fault your logic, and I would do the same if I didnt think it would break an unknown number of things downstream....
This gets repeated over and over again, and still all the MITM scaremongering carries on, while sensible approach of not displaying visual cues for HTTPS with self signed certs, that they are 'secure', but simply encrypting the connection and proceeding to the site, the same way it's done for HTTP is drowned out in the flood of FUD.
What browsers should do is display the fingerprint for the certificate near the URL, so it's easy to verify, but rather than that, HTTPS connections should be treated exactly like HTTP connections, unless there is a CA, in which case the browser should provide visual cues that a third party CA believes this is the actual certificate for the site, that the browser connects to.
You can't handle the truth.
OpenSSH still works fine using the equivalent of self-signed certificates.
Until someone wants to commit a man in the middle attack on you and then you're screwed. The one way that SSH works better than SSL is that it tells you if the certificate has changed, which current browsers don't seem to do; that means they have to do a man in the middle attack before the first time you connect and SSH caches the key.
I've never said self-signed certificates are perfect, only that they do offer benefits over unencrypted connections.
And huge potential security holes which completely break signed key security. If I go to https://mybank.com/ I sure as hell don't want my browser to accept a self-signed key without warning me.
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?
Probably none, because I don't believe that any browser ships with support for StartSSL and hence will treat it as an unsigned key.
The problem with SSL is that browsers accept far too many 'authorities' not too few.
look at openvpn team, they use selfsigned certs together with ca.crt, and y also can publish your site ca.crt on your web. you can show server and cliennt ip/domain on web page, so, you can100% avoid mitm attacks.
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.
Yeah, because when people go to https://mybank.com/ and someone sends them a fake certificate it's much better to just not put a lock icon in the status bar than to put up a huge warning page saying 'YOU ARE GOING TO BE PWNED!'
It may not be "right" for me to think this way, but IMHO when it's a big name company like Google, Microsoft, etc. that everyone in the WORLD has heard of additional scrutiny should be given before handing out these certs when compared to your mom and pop shop.
Check out my lame java blog at www.javachopshop.com
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.
The obvious solution is: don't display "https" or the "golden padlock."
There's no reason why browsers have to display "https://" or even "http://". The average non-technical user doesn't care about the protocol; they just care about the "golden padlock." On the other hand, the average technical user already knows what's going on.
Nobody here is arguing that self-signed https connections deserve a "golden padlock." That's your own straw man.
The proposal is that we should treat self-signed https connections the same as unencrypted http connections. The same. Not worse. Not better. The same.
I have yet to see anybody articulate an even remotely coherent argument against this proposal.
Yeah, the Iranian IP thing is just sensationalism. If someone's stealing SSL certs I think making them use a US proxy is going to barely be a speed bump.
Check out my lame java blog at www.javachopshop.com
The only way HTTP is vulnerable is if you can sniff the traffic. THe only ways you can sniff the traffic are
1) Be physically in the middle of the traffic (you have control of a proxy, or a router, between user and server.
2) Be on the same switch (or hub) as one of the endpoints, and use ARP poisoning to intercept all traffic to one of the endpoints (logically in the middle of traffic).
3) Have a managed port with a mirror port.
In the first 2 scenarios-- which are by far and away more likely than a hacker getting access to a mirror port on your network-- you have a MITM scenario. HTTPS is USELESS if it doesnt guard against MITMs unless your "protected against" list consists of mirror ports, and "hackers" who dont know how to use Cain and Abel (and im not actually sure you couldnt MITM on a mirror port, either). 90% of the time you can sniff traffic, you can intercept it and spoof a response from the end server.
I can believe that the IP address came from Iran, but there is no proof that the machine was under the control of Iranian government as has been alleged in various news accounts. Iran, like any other country on Earth have machines that most likely run some version of Windows and those Window machines are likely to botted as any PC in the US could be. In fact, I'm not even sure that MS can sell Windows in Iran under US embargo restrictions, so the likelyhood of the machine running a pirated version of Windows dramatically increases the chances that the machine is botted since MS blocks updates to pirated versions. The whole thing kinda smells like a false flag op to me. Of course, I'm prepared to accept that the Iranian gov. hackers might have been really stupid as to launch their attack from their own IP space. Hackers have done stupider things, e.g HBGary...
With SSL/TLS, with a self-signed certificate, the attacker has to be in a position to tamper with the packets
No, he just has to be in a position to snoop the traffic and forge replies, and then convince the end user that his certificate is just as valid as the legitimate destination.
Guess what, if you can see the HTTP traffic, youre probably 90% of the way there.
How about making the Federal Reserve Board the CA for the banks in its system? I've always been puzzled by the fact that there aren't more sector-specific CAs backed by large recognizable public or private entities as compared to the Comodos of the world.
Cain and abel already works and makes it trivially easy to arp poison, as does ettercap. There are already point-and-click WEP and WPA (dictionary) crackers out there. And regardless, firesheep doesnt screw with SSL cracking, it looks for unencrypted login cookies.
Well, it means that he won't be able to browse www.eff.org via https since they use a Comodo cert. However, it isn't necessary to delete the certs altogether, just modify the trust bits in your cert manager. I did that with the UTN-UserTrust (the Comodo cert reseller who actually issued the bogus certs) certs. Also, if you run Firefox, be sure to check the box for rejecting a cert if it fails to validate via OCSP.
In the end it yet again comes down to public education, or lack of such, related to the subject.
comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
As an attacker, I'd just intercept all DNS requests, use a bunch of glue records to provide valid, but untrue DNSSEC records at higher levels which other DNSSEC records would validate against. Using a pregenerated seed, I could generate lots of records live on the fly extremely quickly too.
Your DNSSEC aware resolver isn't going to do much against someone who can do a proper MITM attack.
Change is certain; progress is not obligatory.
I don't really follow you, but I'm pretty sure DNSSEC isn't vulnerable to MitM attacks, since that would be really really damn stupid.
Actually, the American public is pretty much at the intelectual level of a 5 year old listening to fairy tales. Say it's from USA or Canada or France - than it's a rogue crazy man (ever heard of Unabomber? the nation had no connection whatsoever). Now, choose one "soon to be civilised country", say someone from Eastern Europe, maybe Russia, or some enslaved US nation (Columbia, anyone?) and you have the feared Organised Crime. You know there are gangs or hordes of organised individuals going against what we call civilisation and holding the country from becoming something great. And you have the third tier, or the Third World, and that is State Organised Crime. Where the State is doing everything in its evil powers to fight the nice guys with their underpants over the suit and kitchy capes. Why does this state of moronship should be a standard for the rest of the World?
look at openvpn team, they use self-signed certs together with ca.crt
Yes, but openvpn has the luxury of always working among the same peers, who know each other, and (presumably) have a way of pre-establishing trust in their certs by exchanging them over a known secure channel (CD, USB stick, ssh) during software installation.
A random https usually does not have this possibility. Maybe your bank could do it, but certainly not amazon or computeruniverse.net.
and y also can publish your site ca.crt on your web.
... and how do you make sure that a Man-in-the-middle didn't intercept it, and change it another ca.crt where he has the private key to?
you can show server and cliennt ip/domain on web page, so, you can100% avoid mitm attacks.
huh? say again?
Question #4, on the list, perhaps.
Why, if Google's certs come from Thawte, is it that big a problem of Comodo issues a bogus google.com cert?
Browsers should remember that Google's certs last came from Thawte (a particular root cert) and today, all of a sudden, it is being verified by another company. Browsers should warm you about this. I know a lot of people would just click "yes" and be done with it, but I think also given it would happen worldwide (in the case of a worldwide attack) would bring the story, the presence of new and possibly fake certs to the fore.
Also, on another note, companies like Comodo should flat out just cache Alexa or something and require additional verification before issuing a cert for a high-traffic site, especially if they don't have them as a current customer.
http://lkml.org/lkml/2005/8/20/95
Here are a couple Firefox addons that can help you avoid compromised certificates/CAs:
In going through the Cert Store in FF4, I discovered a number of them that were completely unchecked, indicating that the Mozilla Foundation/Org doesn't trust them. If that's they case, why in hell are they still in the store?
If they're untrusted then remove them and start cleaning things up. If we actually need them, they can be installed at that time just like any other certificate.
Mod me up/Mod me down: I wont frown as I've no crown
4) the guy at the table next to yours in a cybercafé
He has the possibility to passively sniff your traffic, but attempting to change your packets would draw serious attention (because he really has no way of suppressing the original packets from the air, so both the unmodified original and the spoofed packets would end up hitting the Wifi access points, leading to weird errors...)
+1 Helpful
There's no reason why browsers have to display "https://" or even "http://".
Except, that's a significant part of the address. "http://somesite.org" and "https://somesite.org" could, potentially, point to different content (certainly different vhosts). Yeah - its a mess (often leading to redundant use of the protocol string, port number and "www" subdomains), but browser designers aren't in a position to fix that from their end.
Nobody here is arguing that self-signed https connections deserve a "golden padlock."
No, but browsers do need to advise non-technical users, who don't understand the technical distinctions, in the simplest justifiable terms whether a connection is "secure" or "insecure".
The proposal is that we should treat self-signed https connections the same as unencrypted http connections.
Sites using https generally do so because they want to exchange sensitive data, and the use of a self-signed certificate might indicate that a MiM attack is in progress, or (possibly more likely) that the site is being run by a cowboy outfit who can't be arsed to get proper certificates. So, a self-signed https connection is always slightly fishy (there are plenty of innocent explanations, but identifying those requires human judgement + technical understanding).
I have yet to see anybody articulate an even remotely coherent argument against this proposal.
So, where is the best place, for a browser to start ringing alarm bells? Technically, (1), because you shouldn't be sending sensitive information over http, and the browser can't reliably tell what constitutes "sensitive" . In practice, however, this is incredibly obtrusive (there's plenty of non-sensitive items you can enter in a browser) and risks "training" users to ignore warnings.
I'd suggest (3) is by far the best place at which to start nagging - most users will rarely encounter this situation (only sites with very small user bases, like home servers or in-development sites have a real excuse for not getting a cert) so you're not going to swamp typical users with bogus warnings. For the typical user, this does mean that something out-of-the-ordinary is happening.
And remember at the end of the day, all browsers like firefox actually do is warn you, encourage you to view the certificate and decide whether you want to trust it temporarily or permanently - using language that will deter anybody who doesn't understand what is going on. That's pretty good practice for anybody encountering a self-signed cert. Its annoying if you're a web designer testing sites using self-signed certificates, but you are not the target audience.
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
You can't find me, I'm behind 4 boxxies!
-l
Help cure AIDS, cancer, and more. Donate your unused computer time to worldcommunitygrid.org. Join Team Slashdot!
Wifi more secure?
I don't think so. Injecting packets is not going to be a lot more tricky.
Not to mention you have to trust the wifi operator or anyone else that can gain conteol of the AP/router. Pretty trivial in a lot of places.
Indeed. The only thing I would like more is some threshold settings that work for me. I only want to read 30 or so comments per article, but threaded for handiness. Usually, I just pick a points level that corresponds to that value. I'd rather that be done for me.
-l
Help cure AIDS, cancer, and more. Donate your unused computer time to worldcommunitygrid.org. Join Team Slashdot!
And regardless, firesheep doesnt screw with SSL cracking, it looks for unencrypted login cookies.
I was suggesting that someone may write something akin to firesheep that integrated the extra hacks required to attempt to MitM the SSL connection, and if/when that happens your self-signed connections are no safer than plain text ones.
There's no reason why browsers have to display "https://" or even "http://".
Except, that's a significant part of the address. "http://somesite.org" and "https://somesite.org" could, potentially, point to different content (certainly different vhosts).
Web servers already display different content to users based on their geographical location or their login cookies or any number of state variables, and these content changes are not reflected in the URL. Your point means nothing.
Sites using https generally do so because they want to exchange sensitive data, and the use of a self-signed certificate might indicate that a MiM attack is in progress, or (possibly more likely) that the site is being run by a cowboy outfit who can't be arsed to get proper certificates. So, a self-signed https connection is always slightly fishy (there are plenty of innocent explanations, but identifying those requires human judgement + technical understanding).
This is a tautology. Since today's browsers are so alarmist about self-signed certificates, the use of self-signed certificates is automatically fishy. If you remove the alarmism then the amount of legitimate usage of self-signed certificates would increase dramatically.
self-signed https = someone could be mounting a man-in-the-middle attack or you may have been spoofed/phished to the wrong website.
The same holds for regular http. Someone could be mounting a man-in-the-middle attack with regular http.
Meanwhile, there is one big difference between http and self-signed https that you omitted. With regular http (and only regular http), large-scale attacks like police surveillance and content filtering become possible. https (even self-signed) prevents large-scale passive attacks.
I'd suggest (3) is by far the best place at which to start nagging - most users will rarely encounter this situation (only sites with very small user bases, like home servers or in-development sites have a real excuse for not getting a cert) so you're not going to swamp typical users with bogus warnings. For the typical user, this does mean that something out-of-the-ordinary is happening.
Again, the fact that self-signed certificates are out-of-the-ordinary is a tautology that you helped to set up by insisting that they be treated as out-of-the-ordinary.
And remember at the end of the day, all browsers like firefox actually do is warn you, encourage you to view the certificate and decide whether you want to trust it temporarily or permanently
NO! That's not what firefox does. If firefox did in fact do what you claimed it did, then I would be happy.
In practice, firefox effectively blocks self-signed certificates entirely. It takes five (count them, five) mouse clicks to connect to a self-signed https site in firefox, compared with one mouse click in IE. A regular user is scared away after even one mouse click, much less five. Thus in practice firefox ends up blocking self-signed certificates entirely.
Regular http has no warnings whatsoever, even though every attack against self-signed https is also possible against http, and some attacks against http are not possible against self-signed https. This situation is absurd beyond belief.
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?
Probably none, because I don't believe that any browser ships with support for StartSSL and hence will treat it as an unsigned key.
http://en.wikipedia.org/wiki/Startssl#StartSSL - it would appear that StartSSL's root CA cert is trusted by most common browsers according to that article, though I've not verified this in any way myself yet. If I'm understanding right then the only major population of users with an up-to-date browser that don't have their key trusted is those using IE on XP who have not installed the "certificate update" patches (which aren't marked as important so don't auto-install). While there may be a number of groups of people with out of date setups, most will have browsers that trust a StartSSL cert and those that don't will get the same sort of warning (and lack of protection) as with a self-signed cert but won't be any more/less inconvenienced.
The Comodo root cert should have been revoked, since it was used to generate bogus certs (and who's to say they have a good audit trail to id the affected certs). They should have to recertify their processes before being given a new root cert, and their legitimate customers should have been forced to request new certs (and yes, that is a hassle for their paying customers, but they should look at that as an opportunity to switch to a "better" CA, or to switch to self-signed certs and screw this facade of legitimacy given to the CA companies granted by the browsers).
Patches to the browsers for the individual certs? That's not what the process is supposed to be, that's way bogus.
I'd put it slightly differently:
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).
confusing a specific tool (encryption) with a different tool (authentication).
If you use a self-signed cert, you can guarantee that the guy sitting next to you using starbucks' wifi cannot read your 'hunnybunny' slashdot posts. You cannot guarantee that the website you're connected to is slashdot however, but you can't do that with plain http either.
So we have 3 desired scenarios, or which only 2 are provided for by the current systems:
1. plain old http where anyone can see what you're up to.
2. full-on https with encryption of all your traffic *and* certainty that the destination is who it says it is.
3. a middle ground of encryption where you trust the destination is ok (or you don't care so much if you are victim of a man-in-the-middle attack)
I'd say a system where the self-signed certs are not blown up as huge security risks, but gave you a warning and a red padlock or similar, then we'd get some benefit from the 3rd, middle-ground https.
I think the average user wouldn't understand it though - people who think the blue E is "the internet" - and for them, they've just about grasped the padlock concept. Telling them there's a third option would take some doing!
The only thing HTTP is vulnerable to that HTTPS is not vulnerable to is a passive attack. In most cases, when someone is able to position themself between you and the internet and listen in, they can also modify your traffic and give you bogus certs if you insist on HTTP. Then, because you see the happy, friendly padlock, you are reassured that everything is fine and dandy and nobody is listening in on your connection just because the attacker gave you a certificate which doesn't happen to be the right one.
Sorry i'm lazy. Whats the difference in D1 and D2 ?
I tried them both and they both show me a huge (about 50% vertical) grey area at the bottom of the page.
There was a time, not that long ago, when someone faxed Verisign a request for the private keys for Microsoft's SSL certificates and Verisign responded by handing the keys to them. No verification that the person was legit. DNS providers were just as vulnerable, with people sending in requests for zone transfers by e-mails with forged headers, faxes, letters on stationary not bearing any corporate logo. It worked often enough for there to be numerous scandals.
As for China managing to trick the top-tier routers to re-route half the world's Internet through their packet sniffers... Well, I never was a fan of BGP, and I've grown to loath it all the more.
Getting back to SSL, first nobody should be using SSL 3.0 any more. TLS 1.2 is the current standard and has signficant improvements. Sadly, none that would install a brain into the heads of PHBs or half-asleep cert techs, but it's better than nothing.
Second, let's look at how other people solve this problem. In the physical world, official documents to do with identity usually require at least one witness to countersign and a recognized notary office to stamp the document to reduce the risk of tampering. In the GnuPG/PGP world, it is not unusual to have keys digitally signed by "witnesses" and GnuPG uses an algorithm to reduce the risk of tampering. So clearly, these kinds of procedures have a digital parallel in use.
How would this work in SSL? Well, you could have it so that if organization A knows that organization B's certificate is genuine and correct, organization A could counter-sign B's SSL/TLS certificate as an extra layer of trust. (If a fake Google certificate had a few dozen counter-signatures, all from Iran, it shouldn't be hard to figure out it's fake.)
Or there could be secure public fingerprint servers, where instead of a simple upload (as per MIT's keyserver), the verification of identity by the keyserver owners was every bit as strict as implied by the certificate grade. The cert fingerprint would then be uploaded by the owners and digitally signed by them. A browser, on seeing a new key, could then ask if you wanted to verify the key against one of the known public fingerprint servers rather than giving a technical analysis most users can't understand.
Or we could dump the SSL/TLS approach and go with a different site authentication mechanism. It's not like there's a shortage of them, it's more that Netscape implemented SSL and so nobody really bothered with trying to adapt the others. (Ok, there was a short-lived SHTTP, in addition to HTTPS, but I can't think of any other real effort for website authentication since then. Site-to-host authentication should be standard for all services, since the connection has nothing to do with the service, it's just a connection between a site and a host.)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
OpenSSH still works fine using the equivalent of self-signed certificates.
You seem to be misunderstanding the SSH protocol in this case, and seem to be assuming it protects you in a way that is doesn't. The intention is that you know the server fingerprint by some means (i.e. is has been transmitted to you by a method other than the connection to that server) before your first connection or you are absolutely 100% sure that there is nothing between you and the server that you don't control when you make that first connection. If you blindly accept the fingerprint of the server's certificate the first time you connect without verifying it via another source then you have absolutely no definite assurance that you are talking to the right machine rather than a nefarious one. Once the certificate is accepted SSH protects you from MitM and other attacks by protecting you against the certificate changing (unless there is a significant breach at the server, a MitM attacker won't be able to replicate the keys so their fingerprint should never match), but is does not protect you at all on first connection unless you verify the fingerprint before accepting it.
The SSH method is not practical for a public HTTPS service as you have no practical way of transmitting the certificate fingerprint to every user beforehand for them to verify (and for a private HTTPS service, create your own CA key for signing certs and have your users install that in their browser trust lists).
What OpenSSH protects against is unexpected changes to the certificate, and the certificate being wrong initially if you properly verify the fingerprint (rather than blindly accepting anything) on first connection.
HTTPS with a properly signed certificate protects all connections, even if you can not verify the certificate by other means yourself on first connection.
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?
I don't see why they wouldn't. How would most users even know it had happened? The cynic in me suggests that the only reason some don't do this already is that not enough marketable information is transmitted that way for it to be worth the effort - if a higher proportion of traffic worth scanning (for selling to advertisers and such) was via HTTPS with self-signed certs then maybe some would start.
On every connection their customers make?
It would not need to be that inefficient. Just keep a cache of certificates that you have generated, so you only have to do the generation step once per server name. OK so you still have to do the decryption and re-encryption on the scanning proxy as the stream passes through, but that isn't an expensive operation with modern hardware.
I could name one company (a defence contractor) who does this in their transparent proxy for all outgoing connections so they can monitor for trade/state secrets being passed around that way (and their machines trust their own internal CA cert, so the proxy can generate valid looking certs for anyone's services (even, for instance, Google's) and browsers on their network wouldn't know). It is possible and practical, so if it were in some way profitable for ISPs to do this with self-signed certs they probably would.
I've never said self-signed certificates are perfect, only that they do offer benefits over unencrypted connections.
The benefit is small though, and there is a potential significant cost to accepting self-signed certs without warning. If I somehow poisoned your ISP's DNS server (there have been bugs in bind in the past that made such attacks easy) so that connections to gmail went through my server, I could self-sign a certificate with the right name and forward the connections on. In this case you would not know that som
Way back in the beginning, when we all still remembered using mosaic as our browser, I talked to a representative of Verisign. who assured me that nobody would ever lie about who they are because they have to sign a contract that says they won't. How very confidence inspiring!
Two reasons:
1) Because the cas aren't domain-specific yet. .bank, it would be conceivable to ask the commercial CAs not to issue certs for it, and give a monopoly to the Fed's ca
If the banks had a
2) Because the fed is only for American banks
This is not solvable, the fed doesn't control anything but US banks, giving it control over China(and others) banks won't happen.
Not at all. The current state of affairs is that self-signed certs are treated almost as bad as invalid certs. The site's identity with a self-signed cert is just as good as an unencrypted connection would be (but no better) but it is more secure against 3rd party sniffing. I would rather it look the same as an unencrypted connection (no lock icon, no green trust indicator) rather than the OMFG IT'S A SELF-SIGNED CERT!!!!!!!!! click here, here, here, and here, gee, it was nice knowing you! like it does now. Perhaps it should display a 'cone of silence' icon.
However, if the cert has changed since the last time I visited a site, especially if it's now signed by a different authority, I should be concerned MORE than a self signed cert, especially if the previous cert shouldn't be near expiring yet.
The problem is that trust is fine grained and multi-dimensional but is presented as a simple go/no-go threshold.
Some MitM methods are discussed in http://www.isoc.org/isoc/conferences/ndss/10/pdf/17.pdf if you're curious.
I was however discussing another method which is far simpler. Since DNSSEC doesn't have authentication for glue records and since glue records are essential for Internet operation, you might begin to undertand a problem. Consider being able to intercept all DNS traffic on a network and have a glue record set as root that points to your your own DNSSEC root keys etc. It won't make any difference to a DNSSEC resolver, which will have to accept it as valid by design.
Change is certain; progress is not obligatory.
Right, it is just as good (or bad) as an unencrypted connection, so display it as if it was unencrypted, don't make the user jump through hoops.
The Global PKI system is the largest house of cards ever created.
There are a number of issues:
First and foremost OCSP is bullshit. It can be used to track site usage on a massive scale and is an unecessary reliability and performance dependancy. It allows CAs to hide dirty laundry by keeping a complete listing of their epic fails hidden.
Periodically checking CRL lists is better in my view however there is some lag involved and browsers must be configured by default to fail SSL sessions if CRL checks are sufficiently stale.
Most SSL sites you end up having to login to... What we really need is TLS-SRP support in browsers so you can login to the site using mutual authentication of shared credentials. With TLS-SRP aware browsers even if the SSL cert or servers private key is compromised it does not effect security for existing users.
Finally SSL CA function should just be put out of its misery and punted to DNS already. When CAs advertise 100% automated CSR approval process paying the $100 or whatever it is a month is frankly absurd.
Erm, you could indeed redirect the user to your own root DNS server, but then none of the DNSSEC replies you sent would have the correct signatures (since you don't have the real private keys used by the actual root server).
Obviously the browser has to already have the public keys for every root zone, but that's no different to SSL certificates. And DNSSEC has to used at every zone.
I know exactly what the protocol does and doesn't protect me from. I also watch how normal people use computers. I've watched people blindly accept the warnings from PuTTY when servers have been rebuilt or had their SSH keys regenerated. I've also seen people blindly ignore certificate errors. I would like to be able to walk into my bank and verify the fingerprint of their SSL certificates with them directly, but I doubt they would have a clue what I was talking about.
Firefox extensions such as Certificate Patrol provide similar functionality for SSL certificates (self-signed and those signed by CAs).
My understanding is that there are banks who do this too for similar reasons.
Compared to unencrypted connections? I can log in to a website over plain HTTP without any warning from Firefox. If the site were to use a self-signed certificate and I tried to log in over HTTPS I would get a big scary warning. That seems the wrong way around to me.
That's good in theory. The issue this has highlighted is that the trusted third parties can't be trusted to reliably do their job. A look through Firefox's root certificates lists Comodo (who, not for the first time, have issued certificates to the wrong people), Verisign (who I don't trust thanks to Site Finder) and BT (who I don't trust thanks to Phorm). There are probably many on Slashdot who don't particularly trust Dell, Google and Microsoft either. This is why I much prefer PGP's web of trust approach to X509's strict hierarchy.
One of the nice things about Certificate Patrol is it highlights all changes to certificates since the last visit, and flags if the previous certificate was approaching its expiry date. If my bank's site suddenly changes from being signed by Verisign to signed by Comodo despite having 6 months left on the old certificate, Certificate Patrol will throw a warning.
https with self signed cert protects against passive eavesdropping, plain http does not
Mod this up! Passive eavesdroping is MUCH easier and much more common than active MITM attack (see Firesheep etc.). Nobody's saying that MITM is impossible, but I'd go so far as to say that the difference between plain HTTP and self-signed HTTPS is greater and more important than the difference between self-signed and CA verified HTTPS (and all the fake certificate scandals only confirm this).
The system would warn you of the switch and you have to decide whether to believe Google switched or whether this is a fake.
Like I said, I know that most people wouldn't answer the question (trust or not) correctly and thus wouldn't personally be protected, but the presence of this message on many people's screens will as a whole at least make sure the impersonations didn't go unnoticed for long.
http://lkml.org/lkml/2005/8/20/95
Self signing isn't enough - simply because of MiTM attacks. (A self-signed certificate does not guarantee that it is encrypted at all. You think you have "Computer -- ssl -- webserver", but the true situation could be 'computer -- ssl -- attack proxy -- ssl -- webserver", where the attacking proxy simply terminates two SSL connections and generates a new self-signed certificate to feed back to the computer.
Before you ask, this is brain-dead trivial to implement in, say, a cyber cafe or a cellphone provider. Heck, with proxy arp type attacks (where they intercept traffic destined for the default gateway), another node on the network has to be running the attack. (Reasonably straightforward in a public wifi situation). Compromised firmware on a cable modem would be easy too.. there are already commercial products that do this in the name of monitoring in enterprise networks (they cheat by requiring workstations to add a 'compromised' certificate from the device as a trusted CA.)
My suggestion? Roll on using DNSSEC instead of a certification authority though. Realistically, most CAs warrant nothing more than 'the IP you're connecting to has something to do with someone that once had some control of this domain name and possibly still does". DNSSEC provides better guarantees than that.
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.
Which, as has been repeatedly demonstrated, works really well. :-\
"City hall" in German is "Rathaus" Kinda explains a few things......
Errata:
Self-signed HTTPS: except if your browser had visited the site before and could warn that the "new" certificate was not signed by the same party.
CA-signed HTTPS: except if the CA has been compromised into issuing a bad certificate...
Did I get that right?
Sorry, I don't agree. The true bad idea is for your browser to accept certs from 650 different possible companies as being valid for google.com when in reality most of them never really could be. Virtually all of the time, the only valid cert today is the same one it was yesterday. And even when it does legitimately change, it's not going to be to "Certigna", "CertNomis", "Belgium Root CA", "Juur-SK" or "Baltimore CyberTrust Root". So even if the user has a 90% chance of clicking the wrong button, the odds still rise. And as I mentioned before, the real point of putting this message up isn't protecting them, it's that a spoof like this will be noticed by the internet community as a whole because these questions will start coming up.
Right now, if this spoof happened, how long would it take before someone noticed they are trusting a bogus Certigna cert when Google's certs had previously (and still legitimately) come from Thawte?
It's not about making things perfect. It's about making things better.
http://lkml.org/lkml/2005/8/20/95
Ok, agree, in theory not possible to trust connection without known CA.
The fact is, that I wouldn't be giving my credit card to an self-signed cert site. But, I would def. feel safer giving them my password. There are varying levels, and I would say that I would rather have encryption when sending passwords over the wire, than not.
Appended to the end of comments you post. The maximum is 120 characters.
The guy at the table next to you in a cyber cafe is essentially on a hub or switch with you if you are using unencrypted or shared keys-- he can see all of your traffic, and you can see all of his. He doesnt have to suppress the original packets, and I believe (though have not tried) that you could quite easily perform the wireless equivalent to arp poisoning-- wifi macs are more easily spoofed/changed than wired, and he could quite easily forge deauth commands and set up a clone "evil" wifi AP and wait for you to reauth to it.
Regardless, it doesnt matter if you suppress the original traffic (like in the hub scenario). AFAIK, as long as you reply with the right headers, and your reply gets there first, your traffic will be seen as legitimate. This is in fact how the DNS flaws of a while back worked-- an attacker would perform a DNS request to his local DNS server, and then bombard it with forged DNS replies, until one of its forged packets hit the right sequence number. The local DNS server would then accept its traffic as being legitimate, and cache the reply.
IIRC, TCP/IP doesnt really have any mechanism for protecting you from such an attack. The sender has no way of verifying the identity of its destination, so anyone who sees the traffic can reply to it, and as long as it isnt stopped by routers or IDS (detecting spoofed ips, or replying with the wrong subnet from the wrong router), the original sender has no way to determine where that traffic came from. Thats pretty much why we have SSL certs signed by a central authority....
We have an SSL account with Comodo, one day one of our sysadmin employee left.
We had his username and password but we did not remember his numeric user id...
Guess what, you need all three to login.
So they sent back via email his original userid, username and password in cleartext...
Seriously WTF?!
Web servers already display different content to users based on their geographical location or their login cookies or any number of state variables, and these content changes are not reflected in the URL. Your point means nothing.
Nonsense. Geographic location, login cookies etc. are not part of the URL. The protocol string is part of the URL. You can't hide it. If a webmaster decides to make their URL ambiguous, that's their decision - but a browser shouldn't make URLs ambiguous by design.
This is a tautology. Since today's browsers are so alarmist about self-signed certificates, the use of self-signed certificates is automatically fishy.
Taking account of the status quo is not a tautology. We have a world where most of the web uses unencrypted http (and is quite happy with it) and https is only used where a "secure" connection is required. Maybe the way browsers treat https is part of the reason for that, but that's far from the only explanation - encryption has a processing overhead and buggers up proxying/cacheing, and the vast majority of websites were passive online hypertext. Nowadays, processors are faster and more and more websites are "dynamic" in some way (which also makes proxying/cacheing less relevant). If you were designing the web today, from scratch, then it might well make sense to use encryption in the default protocol and make the "secure" option entirely about trust - but sadly you're lumbered with the legacy of the 1990s web.
The same holds for regular http. Someone could be mounting a man-in-the-middle attack with regular http.
That's an almost meaningless statement: anybody can simply eavesdrop on regular http. It doesn't promise any security at all. Self-signed https: promises security, and end users aren't qualified to judge when that security is appropriate. I predict that, if you asked random users, quite a few would tell you that "https" meant "secure" but very few would understand the risks of a self-signed certificate.
With regular http (and only regular http), large-scale attacks like police surveillance and content filtering become possible.
...if you are worried about privacy, why on earth would you blindly trust the identity of the sites you visit? Content filtering is easier to achieve by blocking sites or threatening to hit service providers in the wallet, and if https ends up crimping Big Brother's style too much, he'll simply force ISPs to block it. If BB wants to waste time and money indiscriminately trawling through traffic instead of more sophisticated, targetted attacks then that's his (and the taxpayers) funeral.
Again, the fact that self-signed certificates are out-of-the-ordinary is a tautology that you helped to set up by insisting that they be treated as out-of-the-ordinary.
Actually, you're the one relying on a tautology, I have the real world on my side. You are saying that if many more sites used self-signed https: then it wouldn't be unusual for a typical user to encounter it. You are also completely relying on your assertion that the handling of self-signed https in some browsers is the predominant reason for its scarcity. I'm just taking account of what happens in the real world. Do you seriously think that the typical browser user is encountering self-signed certificates on a regular basis, or that they don't predominantly use https for dealing with banks and e-commerce sites which would be expected to have a trusted certificate? The self-signed certs I encounter are mainly my own, and when I do encounter one elsewhere then, yes please, I'd like my browser to scream at me (and to warn off my less technical colleagues).
NO! That's not what firefox does. If firefox did in fact do what you claimed it did, then I would be happy.
Sorry, that is exactl
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
Even real certs are not secure as this thread demonstrates. So presenting certs as secure in the browser is committing the exact same sin that you are objecting against for self-signed certs. The only secure means to verify is secure introduction, or out of band verification.
CAs are not a valid out of band means of verification, they are a global trusted computing base (TCB), and thus are a global point of vulnerability.
Higher Logics: where programming meets science.
Unfortunately, OCSP has been defeated by the character 3.
Anyone know if they've fixed that?
There are automated tools to do both, you just won't hear about them so much.
Look up sslsniff for an example.
Not true. This whole thread proves that CA signed certs ARE vulnerable to MITM attacks, because the CA itself is a single shared point of vulnerability.
Higher Logics: where programming meets science.
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?'"
Anyone in the world can become either a Comodo Reseller or Webhost partner. Any partner can order any Certificate. On their lowest priced Certificates, domain-verified only, the verification consists of being able to get an email address. But if you're al webhost partner they actually trust you to only purchase Certificates for your own clients, and you can order domain-verified certificates without any vetting at all.
You shouldn't need to do a browser update because Browsers should be in contact with the CAs and maintain current revocation lists. In this case, however, the browser guys thought this important enough to issue updates because:
a) some people set their browsers to not check verification lists
b) some networks don't let the verification lists in.
On that other pesky subject being discussed in this thread: Self Signed Certs
If a Certificate is self-signed the popup should simply say that while the Certificate works to encrypt traffic to and from the site, it doesn't prove the site is who it says it is. That should be a good compromise.
Okay, I looked at this a bit more and I see where we're missing each other.
We're looking at different problems. The topic at hand is the broken Certificate Authority model wherein a browser trusts a large list of CAs and is vulnerable to any single CA failing. It's as if you were hanging by a chain composed of all the CAs -- if just one fails you fall. Petname Tool doesn't address this scenario.
The solution to this absurdity is to build a time machine, go back to the 80s and define three protocols "http:", "httpe:" (encrypted) and "httpv:" (identity validated) so users don't grow up thinking https: is secure.
Well said. But why do we need a time machine? https is broken and we need to fix it.
Your whole line of posts is based on some sort of premise that we must maintain compatibility with the status quo. My whole point is that the status quo is so irretrievably broken that we must fix it, even if we need drastic steps such as eliminating compatibility with prior notions of "URL" or "https".
Firefox's hysteria against self-signed https goes in the opposite direction. It reinforces the status quo and makes https (or httpe or whatever you would want to call it in an ideal world) even more unusable.
The problem can be fixed. SSH uses no certificates whatsoever, and yet people successfully trust SSH encryption for root-level access. SSH is a far more robust and secure protocol than SSL ever will be.
My whole point is that the status quo is so irretrievably broken that we must fix it
Good luck with that - grab your lance and chase those pesky windmills off your lawn.
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
Have you ever seen Hacker's response:
http://pastebin.com/74KXCaEZ