SSL Cert Weaknesses Exposed By Comodo Breach 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?'"
Thanks Comodo (Score:2)
Re:Thanks Comodo (Score:5, Informative)
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]).
yeah, that's another question (Score:3)
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
Re: (Score:2)
But how do you know whether google is being impersonated, or if they has really switched to Comodo? You can't as far as I can tell.
Re: (Score:2)
It's a bit hard to trust the trust system in SSL. Everyone should take a look at the authorities in their browser (preferences,advanced.view certificates,authorities in firefox). I have no idea who most of those entities are and yet I am to trust that they won't screw up and issue a cert for google.com (even under orders from an unfriendly government).
SSL certs are both over-trusted and under-trusted (Score:5, Insightful)
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: (Score:3)
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
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: (Score:3)
You would have self-signed certs presented as "semi-secure", which they are not.
Re:SSL certs are both over-trusted and under-trust (Score:4, Insightful)
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.
Re: (Score:3)
Only if the client has the certificate ahead of time. Otherwise it really isn't.
Re: (Score:3)
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: (Score:3)
> 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 f
Re: (Score:2)
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: (Score:2)
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 (Score:5, Informative)
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: (Score:2)
Basically, HTTP is vulnerable to absolutely everything, uncertified HTTPS is vulnerable to almost everything.
Re: (Score:2)
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 ge
Re: (Score:2)
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...)
Re: (Score:2)
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.
Re: (Score:2)
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 th
Re: (Score:2)
Re: (Score:2)
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 diffic
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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/ [mybank.com] I sure as hell don't want my browser to accept a self-signed key w
Re: (Score:2)
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 [wikipedia.org] - 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 group
Re: (Score:2)
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
Re: (Score:2)
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.
open access points (Score:2)
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 trus
Re: (Score:2)
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 ide
Re:SSL certs are both over-trusted and under-trust (Score:4, Insightful)
This gets repeated over [slashdot.org] and over again [slashdot.org], 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.
Re: (Score:3, Informative)
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:
Re: (Score:2, Insightful)
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. (Score:2)
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
Re: (Score:2)
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/ [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!'
Re: (Score:2)
Easy solution: Store self-signed certificate in DNS, access it using DNSSEC.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:3)
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.
Re: (Score:2)
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: (Score:2)
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 i
Re: (Score:2)
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 l
Re: (Score:2)
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
Re: (Score:2)
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 connect
Re: (Score:2)
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 connect
Re: (Score:2)
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 ho
Re: (Score:2)
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
Re: (Score:2)
In the end it yet again comes down to public education, or lack of such, related to the subject.
Re: (Score:3)
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 rout
Re: (Score:2)
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!
Peter Guttman's take (Score:4, Informative)
Re:Peter Guttman's take (Score:4, Insightful)
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: (Score:2)
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: (Score:2)
There really is no proof the hackers are from Iran (Score:2, Interesting)
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: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
You can't find me, I'm behind 4 boxxies!
-l
Two more questions (Score:5, Insightful)
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 (Score:4, Insightful)
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: (Score:2)
I am serious. And stop using the fucking dollar sign for your s's.
Re: (Score:2)
I am serious. And stop using the fucking dollar sign for your s's.
Whooosh. The GP simply meant that CA Cert has no money whereas Verisign et al. all have big pockets and probably share that with Mozilla. Whether or not this is true or if there is an actual technical reason, I have no clue. However, that was his/her point.
-l
Re: (Score:3)
True, browser makers could have all release updates that removed comodo as a trusted root CA instead of just blacklisting the 9 certs that they think were signed. But that would have done the following:
1) Made users of any site who got their cert signed by Comodo see a popup (which they'd probably suffer no ill effects from clicking through, further training users to ignore such warnings).
2) next time a CA got hacked, they'd never admit it since it would mean certain death for the company. So instead of rea
Re: (Score:3)
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?
For the very same reason some resellers of this pitiful excuse for a CA deliver certificates to you before you've even scanned a single document proving you're authorized to ask for it (yes, seriously): Because it would be Bad For Business[tm]. People want to start their damn online shops Real Quick, and people who make these shops don't want to irk the customer by asking for lots of papers and delaying the setup. Like always, business efficiency and security do not mix well.
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?
According to CAcert, we (or rath
some thoughts (Score:2)
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 fo
Re: (Score:2)
Re: (Score:2)
> 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 (Score:2)
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
What? Oh, Comodo. (Score:2)
First time through I read that as "SSL Cert Weaknesses Exposed by Commando Breach"
More importantly... (Score:2)
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 issu
Re: (Score:2)
Re: (Score:2)
TY for the reference point, was unaware of this, always thought Comodo was AV/firewall first...
Re: (Score:2)
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 certs discussion: always note these (Score:2)
Here are a couple Firefox addons that can help you avoid compromised certificates/CAs:
If Mozilla Dont Trust Em - Delete Em (Score:2)
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.
Re: (Score:2)
Well, you could just create an account and get them all at once; it's not that difficult is it?
Re: (Score:2)
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 (Score:4, Interesting)
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:
Re: (Score:3)
Using the old D1 system is the only usable option.
http://slashdot.org/prefs/d1
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:3)
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: (Score:2)
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
Re:Regarding question 1 (Score:5, Informative)
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: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
Except many Iranians would identify as 'Persian', not Aryan, and dissociate the race from the country.
Re: (Score:2)
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?
Does this mean that you cant browse any company... (Score:2)
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....
Re: (Score:2)
wouldn't this be a non issue if we had ipv6 with ip security setup?
IPSEC requires either preshared keys or CAs, so the problems are the same. Plus there's no real indication to the application that it's using an encrypted connection so you still need to run SSL on top.