Forgot your password?
typodupeerror
Microsoft Mozilla Security The Internet News Your Rights Online

Comodo Hack May Reshape Browser Security 144

Posted by CmdrTaco
from the get-it-right-this-time dept.
suraj.sun writes "Major browser makers are beginning to revisit how they handle Web authentication after last month's breach that allowed a hacker to impersonate sites including Google, Yahoo, and Skype. Currently, everyone from the Tunisian government to a wireless carrier in the United Arab Emirates that implanted spyware on customers' BlackBerry devices and scores of German colleges are trusted to issue digital certificates for the largest and most popular sites on the Internet."
This discussion has been archived. No new comments can be posted.

Comodo Hack May Reshape Browser Security

Comments Filter:
  • by Anonymous Coward on Monday April 04, 2011 @10:28AM (#35707844)

    With DNSSEC and DNS based SSL keys, only the single trust chain from the root to the domain can sign the keys.

    • by Lennie (16154)

      I totally agree we should add that, there is just one problem.

      The root, .net and .com and so on are controlled by the US-government-agency.

      So you replace many CA's by one 'CA' which might have different 'priorities' than you.

  • Changes need to be made when an issue is found, in anything for that matter. Not doing so is about as useful as trying to solve the problem by sticking you fingers in your ears and yelling, "LA LA LA LA"

    • Re:Good (Score:4, Interesting)

      by jd (1658) <<moc.oohay> <ta> <kapimi>> on Monday April 04, 2011 @11:49AM (#35708790) Homepage Journal

      In the meantime, I'm using a plugin tha shows the AS of the network I'm connecting to. It certainly doesn't solve the problem, but for right now I can differentiate between a site in the US and a site in Iran that may be claiming to be the same machine. It's pretty weak, as AS numbers aren't enforceable, but unless someone sets up scam sites on different autonomous networks and ensures said networks match the US versions, it provides some basic protection. (Besides, 99.9% of the planet wouldn't know what an autonomous system number was and wouldn't care if they did, and any fake site will be set up for the greatest number of victims rather than the best camoflage.)

      • by dbitter1 (411864)

        Care to share (for those of us too lazy to search)?

      • I'm using a plugin tha shows the AS of the network I'm connecting to

        And how exactly would this plugin work?

        Is this information even being communicated to leaf nodes? Or do you make it a habit to only surf the web from your BGP router's console? (... and even then, I'm sure a man in the middle could spoof it trivially...)

        • by jd (1658)

          The information is indeed communicated to leaf nodes.

          http://www.isc.org/software/irrtoolset [isc.org]

          The Internet Routing Registry Toolset will give you most of the answers you want and the tools to verify the answers the plugin gives.

          If you're interested in knowing what it would take to spoof, the obvious place to start would be the Internet Routing Registry daemon. Though you could also look up RFC 2622 as RPSL seems to be the standard protocol.

          http://www.irrd.net/ [irrd.net]

          • The information is indeed communicated to leaf nodes.

            Are you sure about this?

            Maybe you think you can also see your peer's MAC address? (which you don't, unless you are on a same local network)

            • by jd (1658)

              And since you didn't bother to check the links or use the software, 5 demerits. Any more and you'll go on report.

              • And since you didn't bother to check the links or use the software, 5 demerits.

                Thanks, I've got better things to do than run random trojans on my PC. O, and for the links: please check out this link [apnic.net] which seems to disagree with the feasibility of your "tool".

                • by jd (1658)

                  Are you honestly and earnestly saying that ISC and RIPE are run by black-hats for the express purpose of putting trojans onto your machine?

                  I have heard some insane shit in my life but that has to be about on-par with the "Moon Landing Hoax" conspiracy theory. I really, really suggest cutting back on the illegal substances.

                  Oh, and if you're using Linux, too late. You already use ISC software. Clearly you must already be trojaned. Or maybe just the most insane fruitcake I've encountered in a while.

  • by Marrow (195242) on Monday April 04, 2011 @10:42AM (#35707994)

    Instead of trusting information from certificate authorities, the browsers should have the public key for the major size burned in and security hashed inside the browser itself. That way it can trust it is downloading a real update of itself from its real home. If you have already downloaded a hacked browser, then you are dead anyway. So along with a browser you should get burned in security for the major vendors. Security that does not rely on anyone that can lie to you.

    • by brunes69 (86786)

      Hardcoding anything is a bad idea because it makes it impossible to revoke the certificate in the event it is compromised.

      • Re: (Score:2, Insightful)

        by Anonymous Coward

        "Impossible"? Hardly. He probably means "hardcoded" as in "embedded in the browser's files", not as "embedded in the code". The browser could still have a UI to manage those certificates. And even if there's no UI, it would be possible to revoke the certificate by upgrading the browser.

        • That is what I meant. I should have been more clear.

        • That is not good enough, because that is basically what we have today and was proven so insecure in this last attack.

          It is simply unacceptable that I have to wait days or even hours for a browser patch to come out when an top-level SSL cert is compromised. Such a compromise should be able to IMMEDIATELY trigger a revocation that takes effect globally.

          This is the exact problem that CRLs were supposed to prevent. But they are not implemented very well at all, and nearly always disabled by default in web brows

          • by bendodge (998616)

            I highly recommend the Perspectives [networknotary.org] Firefox extension. It basically compares the cert you are handed to the one everyone else received (including in the past), which would have detected the fraudulent Comodo certs.

          • by dgatwood (11270)

            CRLs are hopeless because they:

            • Become unwieldy if the number of revoked certs gets too high.
            • Cannot provide information about certs that have expired (and indeed, one of the reasons for having to have expiration dates is to prevent the CRL from getting too big).
            • Are expensive from a network bandwidth perspective.

            OCSP (ideally over HTTPS) solves these problems, and is thus a much better solution than CRLs. Really, we should just abandon CRLs entirely and mandate OCSP.

            That said, there is an enhancement th

        • "Impossible"? Hardly. He probably means "hardcoded" as in "embedded in the browser's files", not as "embedded in the code". The browser could still have a UI to manage those certificates. And even if there's no UI, it would be possible to revoke the certificate by upgrading the browser.

          You know that's ... um, no different that putting in the code, right? If you have to deploy a product to the user, putting it in the code is identical to putting it in a file that you distribute with the code.

    • by DarkOx (621550)

      That would also completely break legitimate MITM proxies and such on corporate networks. At least today you can install you private CA certificate and then everything will just work; of course then its up to the people running the proxy to for the organization to decide who to trust.

    • This sounds an awful lot like the current state of affairs in popular desktop Linux distros -- you get your browser from the respositories, where the packages are signed using a key that belongs to the distro.
    • by jd (1658)

      What I'd prefer to see are the following:

      • A public site containing a set of SHA-512 + Whirlpool hashes for a large dictionary of "well-known" public keys, where each public key is verifiably provided by the company that owns it (if the company provides the real keys, then any key associated with the company that is not provided is fake, and any key for the same domain that doesn't match the hash of any provided key is also fake). Browsers can then query this site to see if the key is a publicly registered ke
      • This could be combined with DNSSEC, just list the hashes in DNS. That way both DNS and the key itself have to be compromised.
        • by jd (1658)

          You are absolutely correct. It would not be hard to add a new record type.

          A thought for you: http://www.isc.org/software/bind10 [isc.org]

          ISC are wanting suggestions for what is needed in BIND10, the essentially de-facto DNS server. You might want to put your thoughts together as a single white paper on integrated security and send it to them. You aren't getting much mileage on Slashdot, but you might well provoke some excellent thinking by the people who actually develop DNSSEC and the servers that use it.

  • by rickb928 (945187) on Monday April 04, 2011 @10:44AM (#35708018) Homepage Journal

    SSL is dependent on certificates, and the certificate process is deeply flawed. Microsoft in particular seems to be willing to recognize almost any CA, and yet I have trouble with well-recognized root certificates from Verisign working corrrectly with our software, using OpenSSL. Now we hear that most any CA can mint most any certificate.

    Perhaps there needs to be a true 'root' CA, and at least some domains subscribed to prevent any other CA from delivering certs?

    Gee, this would also be nice in DNS, where 'very well known' domains, such as Google, Microsoft, banks, etc could pay to be put on a 'do not change' list and get a more formalized process for management.

    The reality is that we are well past the 'family business' mode the Internet and ICANN et al relied upon to keep things working.

    Jon Postel must have shed a tear. There is still a need for collaboration, but it's time some of the Internet infrastructure grew up. Please fix this before the governments do. You won't like their solutions.

    • by inKubus (199753)

      What we need is a way for people to get the keys straight from each other without having intermediate signing authorities, as much as possible. Example, your bank most likely has a secure, brick and mortar branch in your town or near you. So, you could simply go to the branch office and they give you the cert and you install it on your browser, problem solved. The issue is that this is beyond most people's abilities. However, I posit that if you use something like a QR code or multiple QR codes to hold

      • by dkf (304284)

        What we need is a way for people to get the keys straight from each other without having intermediate signing authorities, as much as possible. Example, your bank most likely has a secure, brick and mortar branch in your town or near you. So, you could simply go to the branch office and they give you the cert and you install it on your browser, problem solved. The issue is that this is beyond most people's abilities. However, I posit that if you use something like a QR code or multiple QR codes to hold the cert, then people just shoot it with their phone and when they get back they plug their phone into their computer and it updates the certs.

        Because everyone only ever wants to talk securely to businesses that have bricks-and-mortar stores in their area, and Bad Guys can't produce QR codes.

      • They can simply hand out CDs with a two clicks installer which copies the CAs to each browser's authorized list. Seems easier than QRCodes for most people, in my opinion.

        • by Tim C (15259)

          And where exactly do I insert the CD in my phone? Or in my battered old laptop, the CD drive on which died years ago?

          • by jack2000 (1178961)
            usb/miniusb/bluetooth ports, QR pic
          • by DarkOx (621550)

            Honestly you don't really need to exchange the entire certificate, Lets assume you have some way of being sure you are talking to correct party out of band, such as on the phone. They could read you just the thumb print of the certificate. You then compare the thumb print and validate the other information on the certificate. Your system checks it matches a CA you trust. If all those things are true you are pretty safe.

            In the Comodo case you would be safe because the thumb pints of the fraudule

      • by rickb928 (945187)

        I just closed an account late last year with a bank I had done business with for 35 years, through mergers and acquisitions and all. They has no branch within 500 miles - I had moved away from them. How would you like to run over and pick up my cert for me?

        A QR code would be fine, but how is it delivered? From their website? Which one? The fake one that presents me a cert from a CA in Uzbekistan? Beijing? Singapore? Do I trust the CA from East LA any more? Why?

        For a decent attempt at multi-factor s

        • by gbjbaanb (229885)

          I suppose they could email it to you :)

          In reality you just need to find a way that you trust the original delivery of the key, once you've done that all's good.
          So, what would you trust to get the key from your bank?

          Obviously going to the bank's HQ and getting your cert on a gold bar would be best. How else would you know that the bank can safely keep your cash? Or mabe the government coudl start printing QR codes on banknotes - you trust the note in your wallet to be tradeable for stuff after all.

          Other than

      • by CastrTroy (595695)
        I've always thought this was probably the best solution. The number of "really secure" sites that most people need is probably about 20. For the rest of sites, you could probably use some kind of self signing system, with a web of trust, to determine if you have the right key. There's no necessity for slashdot to have the same level of security as a bank.
        • by DarkOx (621550)

          Ok great so by doing that you create a huge advantage of incumbency. That would lead to a whole lot of I'm just going to buy it from Amazon because I already trust their certificate, or whatever method you select. That will pretty bar every small site from the retail e-commerce world unless they sell some niche product you can't get anywhere else.

          • by CastrTroy (595695) on Monday April 04, 2011 @01:19PM (#35709894) Homepage
            That kind of exists anyway. When I go to buy something, I'll often just buy from Amazon because I have experience with them, and know they will get it shipped out on time, and that they have a good return policy, or any other number of factors. I usually don't buy from somebody who just happens to have the lowest price, because there are a whole lot of other things to consider. Maybe more of the smaller retailers would have to adopt something like PayPal so that I don't have to trust the site directly, and then I could just trust PayPal.

            Little anecdote, My university professor who was quite knowledgable in the area of of SSL and other related matters said that SSL addresses the wrong problem. The problem generally isn't somebody sniffing your credit card number as it travels over the ether, but rather that you shouldn't have to give your actual credit card number to the retailer in the first place. That way, I don't have to worry about how secure the retailer's operation is. It should work kind of like OpenID, where I log into "VISA" for instance, and authorize a one time payment from my account to the retailer. The retailer doesn't get any of my credit card information, but instead gets a certificate with an authorization number signed by my credit card company that the payment was valid. Paypal pretty much solves this problem, but it is still a third party. The credit card companies should maintain this system on their own, so that no third party has access to this information.
            • by DarkOx (621550)

              I hope someone mods you up. SSL is trying to solve a bigger problem then just CC processing and e-commerce, but that is a really good idea as far handling CC security online. I hope others see it.

    • by maxume (22995)

      I don't think it is particularly likely that your true CA would be any more reliable than Microsoft or Mozilla or whatever.

      I guess someone could do it and say "Hey, my certificates is better!", but I'm not sure there is any way to actually compel anyone to listen to them, and the current system where the browser vendors compile authority certificates has an awful lot of momentum.

    • by rabtech (223758)

      I wonder... once DNSSEC is widely deployed, can we put SSL cert information in DNS records? Maybe a specific TXT extension or a new record type. It would give the browser a way to automatically verify that the certificate was not only issued by a valid CA but the hash also matches what the site owner says it should be. At least then you'd need a fraudulent cert and control over the target's DNS nameservers. I suspect DNSSEC isn't required to cover a lot of these hacks because getting control of the nameserv

      • once DNSSEC is widely deployed, can we put SSL cert information in DNS records

        Why bother with SSL? With DNSSEC you can put an IPSec public key in the DNS (standard already exists) and then you can create a secure connection at the IP level, so any communication with at IP (TCP, SCTP, or UDP) will work.

    • by u38cg (607297)
      CAs should not be in the browser by default. Consumers should pay to subscribe to companies who issue root certificates, and it would be up to the market to sort out the details of trust, cross-verification, etc. And when $ROGUE_CA goes around signing certs for fakegoogle.com, the market can shaft them.
  • I RTFA, but I don't get why this is marked as Microsoft. There's the odd quote in there from them, but shouldn't this be marked as Security or Internet? Or am I missing something?

    • by Anonymous Coward

      Sooner or later everyone around here will blame Microsoft and proclaim Linux superior, despite neither having anything to do with this, and both being vulnerable in the same way.

    • by AndrewNeo (979708)

      I think the original exploits were due to the systems running Windows.

  • and I don't particularly like them when they make the 'geek' community look bad - because it's only the bad stuff that tends to make the news - but if a result of this hack is that people (the big companies, the governments, the FOSS people with the good ideas) finally get together and work on a safe, secure and sensible way of carrying out net authentication that DOESN'T rely on me handing over my security credentials to someone else to manage, then it is a good thing in my eyes.

    • When have you had to hand out your security credentials for someone else to manage? What kind of bankrupt banana republic security infrastructure requires that?

  • Does anyone believe the Monkeysphere project which aims to bring a Web Of Trust model to this problem is a potential –though long-winded– solution ?

    With all the talk on the subject lately, I'm surprised not to see Monkeysphere mentioned more often...

  • by e9th (652576) <`moc.xedoput' `ta' `ht9e'> on Monday April 04, 2011 @11:07AM (#35708284)
    Instead of the binary nature (it's signed by a CA or it's not) of current certs, how about assigning points to a cert based on how many, and what types of CAs concur as to its authenticity. For example, a cert for amazon.com signed only by government agencies, or only by one CA, could be trusted less than one where amazon.com has proven its identity to, say, Thawte, Verisign, and Comodo. The expense to smaller businesses might be a problem, though.
    • by Amouth (879122)

      its a workable idea to have a requirement of having more than one CA recognize it - BUT in the end it has to be binary in nature to the user - when you start bringing a "degree of trust" to the end user - you are having to rely on the judgement of the end user which or all cases is basically random. If it is good/bad then the odds tip that people will choose good - but if you give them more options it will not help them.

    • by mpe (36238)
      For example, a cert for amazon.com signed only by government agencies, or only by one CA, could be trusted less than one where amazon.com has proven its identity to, say, Thawte, Verisign, and Comodo.

      On the other hand it might make more sense to give more weight to the city of Seattle, Washington, USA. Especially compared with a company in South Africa, a company in Dulles, Virginia, USA and a company in New Jersey, USA.

      The expense to smaller businesses might be a problem, though.

      If you go by by the r
    • by gbjbaanb (229885)

      ooh - taxman issued certs. There's nothing in the world that's not going to be given the same level of scrutiny as those guys.

      The expense might not be a problem, once you've submitted your tax return, the taxman sends you a cert in return along with your bill. They could generate them easily enough, and deliver them as QR codes or on cd for extra cost.

    • So what would display to the user? "Warning: This site has a certificate which is mostly trustworthy, but we're not 100% sure"?

      People are already blind to the warnings about bad certs, and are confused enough about what those warnings are about in the first place (seriously, try to get a layperson to explain what they mean or where they come from, and I doubt you'll find a correct answer from any of them). While I do like the idea you have, I just don't see how it would work in practice since it would merel

  • https://blog.torproject.org/blog/life-without-ca [torproject.org] Of course, this may be asking too much of most people...
    • I do the same. I haven't asked my bank to provide me with their fingerprint, but I did check it on multiple machine using multiple connections (laptop at home, phone at public wifi, desktop at university).

      For most sites, the first access is irrelevant - I haven't registered, so I don't have anything to protect. I just care to ensure that subsequent accesses are made to the same machines, and not trusting CAs is actually better for that purpose.

      • by mpe (36238)
        For most sites, the first access is irrelevant - I haven't registered, so I don't have anything to protect. I just care to ensure that subsequent accesses are made to the same machines

        This is the model used by SSH.
        A vulnerability in the way web browsers tend to do things is that they tend to be silent if things change.. The typical logic is accept anything signed by a trusted CA make a big fuss if it isn't.
      • by bendodge (998616)

        I highly recommend the Perspectives Firefox extension. [networknotary.org] It basically compares the cert you are handed to the one everyone else received (including in the past), which would have detected the fraudulent Comodo certs. Much easier than running around to multiple connections.

        • Wouldn't I be replacing the trust in some CAs with trust in some random guys' "network notary server"?

          Checking the certs manually isn't that cumbersome; I only care to check a few of them (banks, IRS and a couple more) and I use those connection regularly anyway.
          I could do like the guy in the article and call them to get the fingerprint, but I fear asking such technical questions, the heads of the support people might explode :|

  • Isn't this exactly what Extended Validation Certificates [wikipedia.org] are supposed to resolve? Only certain validated certificate authorities are allowed to issue them.
    • by heypete (60671)

      Isn't this exactly what Extended Validation Certificates [wikipedia.org] are supposed to resolve? Only certain validated certificate authorities are allowed to issue them.

      The problem is that any of the CAs that can issue EV certs can issue EV certs to any entity, and they will all be "trusted" by browsers.

      Yes, they're supposed to only issue to entities that they've validated, but that doesn't help if one gets compromised and starts issuing technically-valid EV certs to unauthorized parties.

  • Why do I need to get a CA to issue me a signed cert (and then do the same every 2 years thereafter) in order to facilitate encrypted traffic with visitors? The cert bestows minimal trust, costs me money and causes administrative and support hassle when it expires and needs to be replaced. It's basically a tax on security and not one which is justifiable for individuals or small businesses. I'm paying for trust which doesn't actually exist.

    The irony is that browsers like Firefox & Chrome make a big son

    • by bendodge (998616)

      http://www.networknotary.org/ [networknotary.org]
      Perspectives is a wonderful little Firefox extension (with Chome beta) that does exactly as you suggest - uses a web of trust to automatically bypass errors for self-signed certificates, while also detecting stuff like these fraudulent Comodo certs.

      • by DrXym (126579)
        Sounds neat though it really needs several major browsers to have builtin support to make a compelling case for adoption.
    • by cdrguru (88047)

      How can you have a "web of trust" when there are known to be bad actors using the system? All such a web needs is a single person abusing the system and it completely breaks down.

      Of course, the CAs aren't doing their job which is what they are being paid to do. That problem is somewhat simpler to solve - Microsoft, who is likely the biggest stick in the game, simply revokes CA authorization for any CA that isn't in fact doing their job of validation. You can't tell me that Firefox or Chrome are going to

      • by DrXym (126579)

        How can you have a "web of trust" when there are known to be bad actors using the system? All such a web needs is a single person abusing the system and it completely breaks down.

        Of course, the CAs aren't doing their job which is what they are being paid to do. That problem is somewhat simpler to solve - Microsoft, who is likely the biggest stick in the game, simply revokes CA authorization for any CA that isn't in fact doing their job of validation. You can't tell me that Firefox or Chrome are going to trust a CA that Microsoft has revoked.

        It doesn't break down any more than CAs - anyone can buy a cert with a stolen credit card, or stolen / fake ID. So how is it any worse to just generate certs that rely on a web of trust? I'm also not proposing that it may be suitable in every case. Individuals and small businesses would benefit most. Banks and major sites might find value in the cert because they pay a shitload of money to Verisign to actually audit them... well that's the assumption Comodo's fuckup notwithstanding.

        As for key / signature

  • OK, so we have the geeks looking for the padlock, checking the certificate fields out and so on and so forth.

    Except most of the public isn't doing that. I ran across a pharmacy site that says in clear text that "256-bit encryption is use" but there is no padlock and the URL says http [slashdot.org]:. This is on a shopping cart page that is prompting for a credit card number! They have all the right Verisign seals that link to nice pages that say their site is secure. But there is no security. No SSL. Nothing.

    Of cour

  • You can increase your SSL security today by using Perspectives [networknotary.org].

    It tells you if others are seeing the same cert you're getting from a website. So it protects against MITM attacks.

  • I love how everyone in here talks about "Web of Trust", but this is making HUGE assumptions on the end user's part:

    A) They know what they're looking at.
    B) They know what they're looking for.

    This is a big problem that nobody's recommendation here has seemed to have overcome. You all just assume that they can talk to the bank and know exactly what they're looking for. Like any of you validate your RDP certificates (Windows) or ssh public keys (*nix) when you connect for the first time, seriously? If you do th
  • I think the lowest-hanging fruit is to sandbox the various CA's to certain domains. The Tunisian gov't shouldn't be able to make certs for paypal.com. They should probably only be making certs for *.tn, so why not have the browsers enforce this? Have the browsers only trust Verisign and the big DNS registrars for .com certs... etc.

    I realize that this is a really low-tech fix, and it doesn't go far enough to really solve the problem completely. I also realize that there's a lot of political hand-wringing

Passwords are implemented as a result of insecurity.

Working...