Beta

Slashdot: News for Nerds

×

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

Thank you!

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

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

Comodo Hack May Reshape Browser Security

CmdrTaco posted more than 3 years ago | from the get-it-right-this-time dept.

Microsoft 144

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

cancel ×

144 comments

Implement DNSSEC and DNS based SSL keys (4, Interesting)

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

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

Give all the keys to the king ! (0)

OeLeWaPpErKe (412765) | more than 3 years ago | (#35707984)

Yeah, give all the keys into single hands. Now *that's* a good idea.

Unfortunately, letting people decide whom they do and do not trust is also a non-starter. Or it's a good, optional measure, but it cannot be a default step.

I personally just remove all governments. In reality verisign and thawte issued all certificates I care about. Why I'd need any others, I do not know, but still there are scores of CA's in my browsers.

How about we simply remove all non-free governments ? One more reason for the progressives' favorite city to stop practicing slavery [vladtepesblog.com] . Every year, more "progressive" policies look positively medieval (sorry but after reading how it's "racist" to expect Libya to NOT shoot it's own citizens randomly with sharpshooters, or even demand such a state step down from chairing the human rights council ... I think I'm entitled to some frustration)

Re:Give all the keys to the king ! (2, Funny)

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

I have a better idea, let's turn anything into a political discussion for no reason!

Re:Give all the keys to the king ! (0)

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

I'm down with that. Now let's talk about my proposal for an anarcho-syndicalist commune. For instance, you should the temporary executive be selected, and how should we ratify his decisions?

Re:Give all the keys to the king ! (1)

Yaa 101 (664725) | more than 3 years ago | (#35708748)

It is a political discussion when you ask who to trust and who not.

Re:Give all the keys to the king ! (1)

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

If your DNS is compromised, there are any number of certificate authorities out there who will happilly issue you a domain control validated certificate.

Therefore, using DNSSEC to distribute DNS based SSL keys does not reduce security compared to the existing situation anyway. If your DNS is owned, a forged certificate can be issued either way even through CAs that do their job (which is basically just checking that you're actually in control of the DNS name in question).

Using DNSSEC to distribute DNS based SSL keys sounds like a great way to end the protection racket that is SSL certificates.

Re:Give all the keys to the king ! (1)

hedwards (940851) | more than 3 years ago | (#35708880)

It's not a protection racket. The CAs aren't typically promising that a site is going to be on the up and up, all their promising is that the site is who it says it is. Meaning that they might very well be using your log in information for data mining and whatever illegal activities, but that there isn't a MITM or counterfeit site involved.

You can self sign, but the point of paying is that they're supposed to be doing at least some checking to make sure you are who you claim to be.

Re:Give all the keys to the king ! (0)

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

Nice site you have there. It would be a shame if its SSL certificate expired, throwing up huge certificate warnings in the face of your potential customers, leading them to belive that your site is less secure than a regular HTTP unencrypted site.

How is that not a protection racket? :-) I see paying for a commercial cert as little more than paying to get the web browser on the other end to shut up. Security doesn't enter into it.

Re:Give all the keys to the king ! (0)

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

While I agree that it is bad in principle to give up the redundancy of having a domain trust chain and a SSL-CA trust chain, in reality this merge has long been completed, and not with DNSSEC but plain DNS! You can already get SSL certificates for any domain where you can receive mail to a list of a few "special" local parts. In conclusion, SSL already doesn't protect against an attacker who controls a domain. All the SSL-CAs add on top is another bill. They have of course realized that their lax identity checking has made them superfluous, so now they offer extended validation certificates, where they actually check who is asking for a certificate - i.e. what they should have been doing all along. There's still room for that: You can add signatures of CAs to the DNS-supplied keys and verify them against a CA based trust chain in addition to the DNSSEC based trust chain. Plain SSL certificates, which just certify that someone in control of the domain had the key signed by a CA, can be replaced by plain DNSSEC based SSL keys without losing any security.

Re:Give all the keys to the king ! (1)

thePowerOfGrayskull (905905) | more than 3 years ago | (#35709092)

Unfortunately, letting people decide whom they do and do not trust is also a non-starter. Or it's a good, optional measure, but it cannot be a default step.

Unfortunately, this is the ONLY possible option in the end. Everything else is a stopgap attempt at "solving" the problem that people can't/won't/aren't aware of the need to do this effectively.

In reality verisign and thawte issued all certificates I care about. Why I'd need any others, I do not know, but still there are scores of CA's in my browsers.

You really think that they can't unknowingly issue fraudulent certs? What rock have you been living under?

Educate people. Give them the tools they need to use systems intelligently - make it as easy as humanly possible. But at some point, you need to take the training wheels off.

The rest of your comments are fairly political and out of this discussion's scope. (I mention this only b/c I hate when I make a detailed reply and the respondent picks and chooses the parts he wants to reply to --while ignoring those he has no answer for. I'm not ignoring the rest of your post, it's just not relevant to the discussion here. )

Re:Implement DNSSEC and DNS based SSL keys (0)

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

The biggest adversary of them all, your loving fascist US government, has the root keys. So what's the point?

Re:Implement DNSSEC and DNS based SSL keys (1)

GrumpySteen (1250194) | more than 3 years ago | (#35709806)

Why would the US government bother creating a fake version of a website, issuing a fake certificate to make that website look real, then get you to try and log in so that they can get your login details when they can simply issue a subpoena and force the website to hand over all information about you including the information you can't even access?

I suspect you have no idea what a security certificate is and this is just a knee-jerk "OMG GUBMINT BAD" reaction on your part.

Re:Implement DNSSEC and DNS based SSL keys (1)

Paracelcus (151056) | more than 3 years ago | (#35710432)

Probably only in the sense that different agencies have different methods some of which seem silly, but then that's why we make fun of the "cone of silence" in "Get Smart", which by the way turns out to be real! http://en.wikipedia.org/wiki/Cone_of_Silence [wikipedia.org] .

The Gummermint does lots of really stupid things, many of which fit the definition of evil, and for the most part nobody (the public) ever hears abut them.

Re:Implement DNSSEC and DNS based SSL keys (1)

Lennie (16154) | more than 3 years ago | (#35709702)

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.

How could it have ever been trusted? (0)

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

It looks about as secure as a screen door.

Re:How could it have ever been trusted? (2)

owlstead (636356) | more than 3 years ago | (#35708078)

It was trusted enough when there were about 10 companies that could do the signing. After that, more and more CA's turned up, including governmental CA's. These CA's quickly found out that it is a serious pain in the butt to distribute and install the root certificate to/on the clients computing device. So they went to the major browser vendors and asked to be included.

There have already been interesting goof ups regarding security. Microsoft has had problems for certain, accepting end-entity certs as CA certs for instance, or having a bug overflow in their ASN.1 library (all certs are ASN.1 encoded). As the article said, revocation of certificates is almost never enabled by default. All in all, the default trust-store is becoming more and more problematic.

Personally, I've got the most trouble with the certs of certain governments, I would like to see those restricted to their own domains (e.g. .nl for Dutch CA's), or have them enabled/disabled depending on the location of the computer during install. Ask the user if he wants to trust other installed certificates.

Re:How could it have ever been trusted? (1)

dkf (304284) | more than 3 years ago | (#35708364)

Ask the user if he wants to trust other installed certificates.

There's no point in asking a user a security question they don't understand, especially if it has long-lasting subtle consequences. They'll just say "yes" or "no" at random. We saw that with screensaver trojans. We'll see it again here. Any widespread mechanism must not require lots of fiddling around by users; it's got to be as permissive as possible while still being reasonably safe.

Re:How could it have ever been trusted? (1)

thePowerOfGrayskull (905905) | more than 3 years ago | (#35709288)

Ask the user if he wants to trust other installed certificates.

There's no point in asking a user a security question they don't understand, especially if it has long-lasting subtle consequences. They'll just say "yes" or "no" at random. We saw that with screensaver trojans. We'll see it again here. Any widespread mechanism must not require lots of fiddling around by users; it's got to be as permissive as possible while still being reasonably safe.

The only way to code a technically perfect solution that obviates the need for a brain is to also code the technically perfect user. That said, asking the user that particular question is a bad plan as you said - it's meaningless to the user. Especially if they accidentally click "no" and then don't understand why nothing works.

Our current approach of trying to solve it technologically (via CAs, anti-malware when we're speaking more generally, and other tools) is in large part WHY most users are so unable to comprehend the problem. We give the users tools and say "with these tools you are Safe, so long as you always use these tools". Examples: firewall clients, antivirus software, and "if the icon is blue, then it's safe to use the site". Then we wonder why they don't believe it when they see something that says they're NOT safe.

I've run against that too often. "But I have antivirus, and it says I'm up to date." "My antivirus scanned that email, so the link it includes is OK."

There needs to be a massive effort to educate users on why this stuff is important, and the risks associated with ignoring it. It's a long process, and it requires making people AWARE of security -- and aware that installing the latest AV updates doesn't make them secure. (Of course, the AV vendors will continue to sell their false security, which is a serious hindrance.) THEN you can proceed with a solution that requires the user to use his brain and make a decision. But it's critical that they be trained out automatically clicking the "get me past this annoying screen so I can see my bunnies" button.

Re:How could it have ever been trusted? (1)

Dishevel (1105119) | more than 3 years ago | (#35709880)

Nope.
Education of the masses is pointless and will not be tolerated by them.
Let me be real clear on this. They do not want to know.
They just want it to work and as long as it dose they are just going to click what they want to click.

The only long term solution is two fold.
1. Long prison terms for production and knowingly distributing malware, viruses, adware and spyware.
2. Infected computers are disconnected from the internet automatically. (Users can call the ISP and pay to have their computer fixed so they can get back online.)

Done.

Just because you want on the internet dose not mean you get on the internet.
We do not let idiots drive 90mph the wrong way on the freeway. But somehow letting these dipshits on the information superhighway and wrecking it for everyone else is ok?

I don't think so.

Re:How could it have ever been trusted? (1)

thePowerOfGrayskull (905905) | more than 3 years ago | (#35710010)

I agree at least with both. Because in neither proposition do you suggest trying to protect the user in any way or otherwise make them feel secure. And your part of the answer is not incompatible with my own.

Re:How could it have ever been trusted? (1)

mpe (36238) | more than 3 years ago | (#35709704)

It was trusted enough when there were about 10 companies that could do the signing. After that, more and more CA's turned up, including governmental CA's.

A really big failing is that CA's lack any sense of scope. A governmental CA is probably actually the best entity of verify a business within it's jurisdiction. But can't do so for anywhere else in the world. Thus you really don't want New York City trying to tell you anything about companies outside that city.
Nor does it make sense for commercial CA's to be dealing with anything more than X distance from where they actually have offices.
Since Comodo appear to have no offices in the Southern Hemisphere they probably arn't going to be much use about a business in Aukland. Yet I doubt most browsers would complain about a site with a Comodo issued certificate claiming to be from Air New Zealand.

Re:How could it have ever been trusted? (1)

Lennie (16154) | more than 3 years ago | (#35709780)

That is something I want too.

Restrict a CA to a domain-list.

Possible have an option for: ask to add domain to list.

But it only works for technical users. No noob will understand this, so it isn't a real solution.

Re:How could it have ever been trusted? (1)

jrumney (197329) | more than 3 years ago | (#35708290)

It's easy to say that in hindsight. I raised this issue 12 years ago in a Slashdot thread about the release of IE 5. Judging by the responses and moderation I received, the general consensus at the time was that I was crazy kook for complaining about the proliferation of trusted CAs.

Re:How could it have ever been trusted? (1)

Z00L00K (682162) | more than 3 years ago | (#35709122)

It all comes down to who watches the watchmen.

I don't even trust myself, so how am I going to trust a CA?

Good (1)

The Grim Reefer2 (1195989) | more than 3 years ago | (#35707970)

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

jd (1658) | more than 3 years ago | (#35708790)

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

Re:Good (1)

dbitter1 (411864) | more than 3 years ago | (#35710012)

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

Maybe the browsers should hardcode the major certs (2)

Marrow (195242) | more than 3 years ago | (#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.

Re:Maybe the browsers should hardcode the major ce (2)

brunes69 (86786) | more than 3 years ago | (#35708022)

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

Re:Maybe the browsers should hardcode the major ce (2, Insightful)

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

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

Thank you (1)

Marrow (195242) | more than 3 years ago | (#35708276)

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

Not good enough (1)

brunes69 (86786) | more than 3 years ago | (#35708488)

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 browsers due to this. The SSL registration system needs to be changed to make real-time validation of certificates mandatory somehow.

Re:Not good enough (1)

bendodge (998616) | more than 3 years ago | (#35709346)

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.

Re:Maybe the browsers should hardcode the major ce (0)

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

So then what happens when a major site gets compromised? Every end user has to manually install a new cert? How does a user know when the proper time to do this is? How do you stop a malicious piece of code from simulating that proper time and convincing unknowing users to install bad certs? Particularly after the first time a major cert gets compromised and every person on the planet learns "Ok, when a site stops working, I just click that button to put a new certificate thingy in". Relying on end users to make judgements about certificates on their own is about the only thing that would be worse than the current situation of allowing dozens of CAs to do it. If it requires a browser update, then it's 100% the same as the current situation, although at least in the current situation we have a legit mechanism for real time revocation, unfortunately it's not really used.

Re:Maybe the browsers should hardcode the major ce (1)

thePowerOfGrayskull (905905) | more than 3 years ago | (#35709308)

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

Re:Maybe the browsers should hardcode the major ce (1)

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

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.

Re:Maybe the browsers should hardcode the major ce (0)

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

there's something wrong about calling a proxy designed
to be a MITM as "legit". if we make compromises for
"legit" MITM proxies, how do we prevent the bad guys
from using the same feature?

Re:Maybe the browsers should hardcode the major ce (0)

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

Hey dumbass, he gave you the answer in his statement.

Don't install the CAs.

Re:Maybe the browsers should hardcode the major ce (1)

betterunixthanunix (980855) | more than 3 years ago | (#35708390)

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.

Re:Maybe the browsers should hardcode the major ce (0)

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

MS and Intel want to hardcode certs on chips in all computers, making them require a "license" to go online, which isn't very fair, is it.

Re:Maybe the browsers should hardcode the major ce (1)

jd (1658) | more than 3 years ago | (#35709840)

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 key or not.
  • Keys should be counter-signed by some independent body that can vouch that the key belongs to the key-holder; key credibility should be a function of the current credibility scores for all countersigning bodies. If a key is found to be a forgery, the credibility of the countersigners would go down. The owner's credibility score would remain intact. Countersigners with a good track record should have a score that goes up.
  • There needs to be a second step in the authentication process that is wholly independent of SSL/TLS.

Re:Maybe the browsers should hardcode the major ce (1)

andymadigan (792996) | more than 3 years ago | (#35710572)

This could be combined with DNSSEC, just list the hashes in DNS. That way both DNS and the key itself have to be compromised.

Perhaps we need to validate the CAs? (2)

rickb928 (945187) | more than 3 years ago | (#35708018)

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.

Re:Perhaps we need to validate the CAs? (2)

inKubus (199753) | more than 3 years ago | (#35708286)

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.

Re:Perhaps we need to validate the CAs? (1)

dkf (304284) | more than 3 years ago | (#35708400)

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.

Re:Perhaps we need to validate the CAs? (1)

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

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.

Re:Perhaps we need to validate the CAs? (1)

Tim C (15259) | more than 3 years ago | (#35708742)

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?

Re:Perhaps we need to validate the CAs? (1)

jack2000 (1178961) | more than 3 years ago | (#35709148)

usb/miniusb/bluetooth ports, QR pic

Re:Perhaps we need to validate the CAs? (1)

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

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 fraudulently acquired certs would not match those of the legitimate ones. Its not unreasonable for a Bank to have its customers call in and check a thumb print.

Talking about trust... (0)

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

While I admire your intent to get rid of the middle men, my banks are the last people I would trust to inject an application of any sort into my computer.

I do like the idea of QR codes (or just easily OCRd digits) on a bank statement or new-account paperwork, which could be scanned with the software of my choice rather than theirs. On the other hand, with the way they outsource so much activity now, I also need to remember not to trust any of the official communication paths too much either. Defense in depth unfortunately requires suspicion in depth.

Re:Perhaps we need to validate the CAs? (1)

rickb928 (945187) | more than 3 years ago | (#35708440)

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 security, I need to be able to choose how I find the bank. So if I go to https://www.chase.com/ [chase.com] can I be certain it is the real, legitimate Chase site? How can I tell if it was falsified in DNS, with a cert from a compromised CA, and is just a passthrough to the 'real' Chase site...? When I get a call from the bank? when I read about it on CNN?

Can it be bulletproof any more?

Re:Perhaps we need to validate the CAs? (1)

gbjbaanb (229885) | more than 3 years ago | (#35709304)

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 that, would a 2-part of postal delivery of a CD alongside an email be ok for you? An attacker would have to compromise both, and that's not going to be too easy.
Maybe a postal delivery of a CD, and a separately-sent phone number to phone to verify yourself and get the 2nd part of the key? They do that for credit cards don't they, is that good enough for you?

To guarantee secure comms with your bank's website after that, maybe you would have to send your key to them so every login attempt you make would have the bank authenticate you, would that be ok to guard against dodgy DNS entries? (ie you would never log in using only your userid, you'd automatically be registered with the bank so that it displays your name or special code or whatever on the home page in big letters - something a MitM attacker would not know).

At some point you're going to have to trust that the key was delivered safely, and in the real world that means you're going to have to accept a certain (but small) amount of risk traded against paranoia-busting security.

Re:Perhaps we need to validate the CAs? (0)

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

And I walk into the bank and while I am supposedly "shooting the QR code with my phone", I paste a fake QR code over the real one and the next several people who "shoot the QR code" and trust the results are not getting what they thought there were getting. There is always a way to subvert trust and since CAs are about trust there will always be a way for the bad guys to get in the middle of it.

Re:Perhaps we need to validate the CAs? (1)

CastrTroy (595695) | more than 3 years ago | (#35709284)

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.

Re:Perhaps we need to validate the CAs? (1)

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

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.

Re:Perhaps we need to validate the CAs? (3, Interesting)

CastrTroy (595695) | more than 3 years ago | (#35709894)

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.

Re:Perhaps we need to validate the CAs? (1)

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

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.

Re:Perhaps we need to validate the CAs? (1)

bityz (2011656) | more than 3 years ago | (#35710712)

In a building in my work's tech park, they do entagled photon based quantum key distribution [wikipedia.org] via a laser link with another building.

So if each bank had a bunch of sharks with lasers...

Re:Perhaps we need to validate the CAs? (1)

maxume (22995) | more than 3 years ago | (#35708452)

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.

Re:Perhaps we need to validate the CAs? (1)

rickb928 (945187) | more than 3 years ago | (#35709898)

When did my browser become my CA?

Re:Perhaps we need to validate the CAs? (1)

maxume (22995) | more than 3 years ago | (#35710080)

Well, if you didn't manually review the certificates that it uses by default, whenever that was. At least in effect.

I don't really mean to argue that the browser vendors are acting as CAs, I'm just pointing out you are essentially proposing taking the role of determining what CAs are valid away from organizations and giving it some other organization. I don't see that the technical differences would really change anything.

Re:Perhaps we need to validate the CAs? (1)

rickb928 (945187) | more than 3 years ago | (#35710436)

It works for DNS.

Re:Perhaps we need to validate the CAs? (1)

OfficeSupplySamurai (1130593) | more than 3 years ago | (#35708618)

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.

Perhaps you were already alluding to this, but that is exactly why DNSSEC is such a great idea. The trust of a site being who they say they are belongs in the DNS, since that's the system which is actually responsible for knowing. There are already records that exist to store such things: CERT and SSHFP records can secure web sites, email, and SSH, and with secure DNS such things can actually be useful. Just recently .com became signed, so now all three major TLDs (.com, .net, and .org) are signed, and several others are besides (see http://en.wikipedia.org/wiki/List_of_Internet_top-level_domains [wikipedia.org] ). Once this becomes widely deployed it could significantly improve some issues of trust on the Internet.

Re:Perhaps we need to validate the CAs? (1)

mpe (36238) | more than 3 years ago | (#35709188)

Perhaps you were already alluding to this, but that is exactly why DNSSEC is such a great idea. The trust of a site being who they say they are belongs in the DNS, since that's the system which is actually responsible for knowing. There are already records that exist to store such things: CERT and SSHFP records can secure web sites, email, and SSH, and with secure DNS such things can actually be useful.

Dosn't help too much when the vast majority of TLDs are effectivly DOT misc. (Even before considering "vanity ccTLDs".)
You wind up with similar issues to those current certificate authorities. Specifically how can entity A "verify" entity B when they are hundreds or thousands of miles apart?

Re:Perhaps we need to validate the CAs? (1)

rabtech (223758) | more than 3 years ago | (#35708620)

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 nameservers is a higher bar but it would definitely be required to protect against governments... it would require the country to prohibit the use of DNSSEC, so at least you would know you were being lied to.

This issue seems like the classic problem of trust in that there is a fundamental assumption that the CA will never lie but that has been proven false over and over again.

Re:Perhaps we need to validate the CAs? (1)

OfficeSupplySamurai (1130593) | more than 3 years ago | (#35708772)

Yes, this is one of the reasons why DNSSEC holds such promise. It doesn't even need new records or extensions. The CERT, IPSECKEY, and SSHFP (source [wikipedia.org] ) records have existed for years but haven't been used since they weren't really useful before DNS was secure. Those three can be used to secure nearly anything you might want, with CERT being the catch-all record that can store web, email, or any other certificate. Since DNS is the system that is charged with knowing who a name is, it makes a lot of sense to put the trust there in a single place, rather than the large number of certificate authorities that it seems are not always trustworthy.

Re:Perhaps we need to validate the CAs? (1)

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

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.

Re:Perhaps we need to validate the CAs? (0)

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

Because for every site that does what you suggest there are at least 1 million sites that use SSL (HTTPS).

Why Microsoft? (1)

Godai (104143) | more than 3 years ago | (#35708024)

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?

Re:Why Microsoft? (1)

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

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.

IANAH (I'm not a hacker) (1)

Tigger's Pet (130655) | more than 3 years ago | (#35708034)

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.

One thing we could use in web browsers (0)

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

Free certificates for HTTPS that only implement encryption (not authentication) and don't pop up a giant alarm screen.

Re:One thing we could use in web browsers (2)

jgtg32a (1173373) | more than 3 years ago | (#35708200)

Agreed the treatment of self-signed certs was just stupid. What they should have done was just taken away the "Secure Page" notification in the URL bar, because the current behavior makes a page that submits credentials in clear seem more trustworthy than pages that use self-signed certs. The behavior should have been if the browser sees a submit of a password type then and there is no encryption then complain every time.

Re:One thing we could use in web browsers (1)

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

You can already create certificates using OpenSSL. And most new browsers (FF4, Chrome) don't pop up giant alarm screens anymore.

But CA certs are cheap enough, you can get on for $9/year. I even got min free with a .com domain.

That simply does not solve any problem; the main problem is with authentication.

Re:One thing we could use in web browsers (1)

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

Only implementing encryption is largely worthless. An encrypted connection with an unknown endpoint is no different to an unencrypted one. The guy next to you in the coffee shop whose machine replied to your DNS request with his IP faster than the real DNS server will look (to your browser) just like the host that you were expecting to connect to. You'll end up with a secure connection to the attacker, but that's not really any better than an insecure connection to the attacker.

Re:One thing we could use in web browsers (1)

locofungus (179280) | more than 3 years ago | (#35709878)

This just isn't true.

An unencrypted connection can be attacked at any point in time. A encrypted but unauthenticated connection can only be attacked while it is being set up.

And it isn't even possible for an attacker to tell when it is transparent to attack the key exchange and when the browser actually has the certificate or a plugin to warn that the certificate has changed.

Encrypted connections prevent passive eavesdroppers and force attackers to use active attacks which are detectable if you care enough to want to detect them.

Tim.

Re:One thing we could use in web browsers (1)

Lennie (16154) | more than 3 years ago | (#35709860)

You mean like http://www.startssl.com/ [startssl.com] already does this ? For free for the current CA-system.

Monkeysphere (1)

axx (1000412) | more than 3 years ago | (#35708150)

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

source of du rounds, tear gas, land mines secret? (0)

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

secret mystery of god providing aimlessly? seems as though our rulers get them by default, then, arm the (soon to be) armless/lifeless? yikes. whois in charge of all this madness?

oppressed pop. worldwide receiving arms shipments

many of the newer subscription issues include the even newer miraclemorph prosthetic devices, so that the advanced weapons may be operated by the armless of every discipline, race, motive etc... being fair to all is truly disarming.

censored? chariots? honestly?

Due to excessive bad posting from this IP or Subnet, anonymous comment posting has temporarily been disabled. You can still login to post. However, if bad posting continues from your IP or Subnet that privilege could be revoked as well. If it's you, consider this a chance to sit in the timeout corner or login and improve your posting. If it's someone else, this is a chance to hunt them down. If you think this is unfair, please email moderation@slashdot.org with your MD5'd IPID and SubnetID, which are "blah blah blah

How about a "degree of trust?" (3, Interesting)

e9th (652576) | more than 3 years ago | (#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.

Re:How about a "degree of trust?" (1)

Amouth (879122) | more than 3 years ago | (#35709176)

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.

Re:How about a "degree of trust?" (1)

mpe (36238) | more than 3 years ago | (#35709370)

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 registered address of the business then the size of the business becomes rather less relevent.

Re:How about a "degree of trust?" (1)

gbjbaanb (229885) | more than 3 years ago | (#35709402)

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.

Re:How about a "degree of trust?" (1)

Anubis IV (1279820) | more than 3 years ago | (#35709818)

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 merely aggravate the issue with user blindness and would lead to increased confusion by complicating a process that the users already fail to understand.

Of course, this may just be an interaction issue, rather than a technical one, especially so if it can be demonstrated that your method provides technically better results.

Don't trust CAs at all (1)

betterunixthanunix (980855) | more than 3 years ago | (#35708308)

https://blog.torproject.org/blog/life-without-ca [torproject.org] Of course, this may be asking too much of most people...

Re:Don't trust CAs at all (2)

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

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.

Re:Don't trust CAs at all (1)

mpe (36238) | more than 3 years ago | (#35709460)

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.

Re:Don't trust CAs at all (1)

bendodge (998616) | more than 3 years ago | (#35709570)

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.

Do Extended Validation Certificates solve this? (1)

Chrisq (894406) | more than 3 years ago | (#35708346)

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

I have a suggestion (0)

mysidia (191772) | more than 3 years ago | (#35708406)

DNS Bindings for SSL certificates

Here's how it would work:

Every SSL certificate has a unique SHA1 ID and issuing CA

I suggest we have signed DNS records like this:

web.example.com. 86400 IN A 192.0.0.1
_https._tcp.www.example.com 86400 IN SRV 10 10 443 web.example.com.
_https._tcp.example.com 86400 IN SRV 10 10 443 web.example.com.
_https._tcp.example.com. 604800 IN TXT "v=tls3 subject="/CN=example.com/O=Example Organization/OU=Example OU" issuer="/C=US/ST=xxxxxxx/L=xxxxxxxxx/O=ca.example.com/serialNumber=xxxxxxxxx" ocsp=http://ocsp.ca.example.com/xxxxxx ciphers=aes256, sha1=XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX"
_https._tcp.example.com. 604800 IN TXT "v=ssl_cross_domain_inclusion +https://subdomain.example.com/* +http://images.example.com/* -all"
_https._tcp.www.example.com. 604800 IN TXT "v=tls3 subject="/CN=example.com/O=Example Organization/OU=Example OU" issuer="/C=US/ST=xxxxxxx/L=xxxxxxxxx/O=ca.example.com/serialNumber=xxxxxxxxx" ocsp=http://ocsp.ca.example.com/xxxxxx ciphers=aes256, sha1=XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX"
_https._tcp.www.example.com. 604800 IN TXT "v=ssl_cross_domain_inclusion +https://s

And in addition to having certs signed by a CA, the browser should verify the DNS records. There should also be an attribute on the CA or the certificate indicating that use of the cert will fail if the DNS record is not present.

Also, as long as DNSSEC is used, "self-signed certificates" are no longer bad. So long as the proper DNS records are in place

Root = reliable, not reliable = no root. Simple. (0)

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

I really do not understand why the major browser and OS distributions still have Comodo listed as trusted root.

Problem is not that they have been hacked: problem is that their Italian subsidiary (which is NOT a partner, is themselves) had username/password gtadmin/globaltrust for an administrative access to the certificate signing interface, that tehse credentials were hard-coded in a DLL, that this DLL was parked on a windows PC open like a clamshell on a grill.

When we use SSL we trust the distributors to insert only root certificates handled by people with a minimal (decent?) level of technical skill with some responsibility in security matters: these folks proved to not being able to secure even the PIN of their ATM card. WHY should we trust them anymore ?

WHY, beginning in example with Firefox, the Comodo roots haven't been removed yet ? Yes this would mean having Comodo close down: that's called natural selection (and might be a lesson to other root autorities to go back and study at least the basics of 17799 at least...).

The above are not random claims: http://pastebin.com/74KXCaEZ

You can check on several sources that the claims done by the guy posting that information are correct (he showed the private keys corresponding to the hacked certificates as signed by Comodo).

Re:Root = reliable, not reliable = no root. Simple (0)

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

The whole problem is that Comodo allow "resellers" to sign certificates under their root key (without using an intermediate certificate).

This means that browser manufacturers who declare Comodo as a CA that is to be trusted, in fact assign trust to a completey unmonitored authority.
(because it does allow others, who are not well monitored, access to its trusted root key)

Of course instantssl.it should be immediately removed from the trusted CA list, but it cannot be done because it is not on it.

PGP certs (1)

DrXym (126579) | more than 3 years ago | (#35708966)

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 song and dance of not using a patented video codec, and yet here is a security model which arguably has had a far more chilling effect on the internet.

Firefox et al, really should offer a way for sites to issue their own certs. Not a self signed cert, but a cert that implements a web of trust. The obvious way would be to allow an SSL cert to be signed by a PGP key. When the browser encounters such a cert it fetches the web of trust from a PGP key server and displays that to the user. If the user says they trust the site, their choice is stored in a list which is used for future reference. It could be seen as a kind of key which sits between self-signed and CA signed.

Re:PGP certs (1)

bendodge (998616) | more than 3 years ago | (#35709594)

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.

Re:PGP certs (1)

cdrguru (88047) | more than 3 years ago | (#35709632)

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.

Re:PGP certs (1)

DrXym (126579) | more than 3 years ago | (#35709938)

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 revocation, it would work the way it does in PGP - issue the revocation, upload the keyblock to a key server.

Re:PGP certs (0)

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

Great idea. I wish I had mod points.

SSL is somewhat of a joke anyway (1)

cdrguru (88047) | more than 3 years ago | (#35709604)

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 course, there probably are CAs that will issue certificates to fake pharmaceutical distributors - you know, little blue sugar pills for $2 each - but it is much simpler to just bypass that whole thing and say your site is secure. They are raking in millions of dollars doing this so it is clear that most people aren't checking.

If sites are getting away with this, I'd say that is a much, much bigger problem that trying to secure SSL against folks.

Better SSL Protection TODAY (1)

Onymous Coward (97719) | more than 3 years ago | (#35710066)

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.

Seriously? (1)

magamiako1 (1026318) | more than 3 years ago | (#35710854)

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 that, you have way too much time on your hands.

The only solution to this that seems sensible is either two-factor authentication via a challenge system, something added to DNSSEC to extend on the authenticity, or as some mentioned in here to have the browser check with multiple CAs. But good luck making someone pay for 2+ signatures to their certificate.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

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

Submission Text Formatting Tips

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

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

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

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

Loading...