Can We Fix SSL Certification?

Em Adespoton writes "At DEFCON this year, Moxie Marlinspike gave an excellent presentation showing how broken the current SSL certification model is and proposing a replacement. Naked Security adds to the issue, asking: does it even matter if you can trust your certificate notaries?"

Comments

No

[0123456]

SSL certification is just plain broken; in another decade it will have collapsed in a heap.

Re:No

[WrongSizeGlass]

I've got a great idea. How about we let the government verify both ends of the connection for us so we are assured that no man-in-the-middle attack can take place? Surely that will alleviate any problems, right?

Re:No

[ravenspear]

Yes, the NSA has given us a 100% guarantee that their most secure encryption method and servers will be used.

Re:No

[Anonymous Coward]

"the NSA has given us a 100% guarantee that their most secure encryption method"

Well, we've bought into it so far.

Re:No

[TheSpoom]

Mod parent up. AES / SHA, anyone?

Re:No

[elsurexiste]

Man, what's happening with you? Your comments are usually nice, but lately they are just too aggressive or troll-like. Are you getting enough sleep?

Re:No

[vlm]

SSL certification is just plain broken; in another decade it will have collapsed in a heap.

Agreed. Does anyone have a solution? I'm thinking VPN provider service... connect enduser device to "the mall" and as long as you trust your VPN connection to the mall, and the VPN connection from the mall to "vendor" (amazon, whatever), and you trust the mall itself, that should pretty much eliminate MITM attacks...

The puzzle is, how to convince everyone to switch at the same time, and how to convince anyone to trust "the mall"? Probably, there should be several "malls"

That would seem to be the death of anonymous access, but the whole point was to give a vendor my non-anonymous valuable financial data anyway, so ...

Re:No

[chill]

Actually, that is a good idea.

The articles aren't really discussing absolute trust, they are talking about only one aspect of SSL -- identification.

A root CA doesn't tell me "you can trust example.com", it tells me that example.com really is example.com. The root CA supposedly put the effort in to making sure the domain owner provided supporting documentation to prove they are who they say they are.

This is analogous to what States do in requiring proving identity before issuing a driver's licenses. Or, as Federal Governments do before issuing passports.

We trust the governments with this function now. I don't see what the big issue is in trusting them with the digital version.

Re:No

[Archangel Michael]

Who Trusts the web of Trust?

The only SSL Cert I trust is the one I issued to myself. But who trusts me? And who SHOULD trust me? Same probably goes with you too.

At some point, you're gonna have to trust someone else, and invariably that trust will be broken at some point. So, how do we fix us broken humans?

Re:No

[arth1]

Agreed. Does anyone have a solution?

Adding a "web of trust" as TFA seems to think of as a workaround is worse than nothing. If there is one thing we should all know is that trust cannot be inherited more than one step - your friend's friend's friend is as likely to be working for Cosa Nostra or RIAA (but, I repeat myself) as being trustworthy. Or he's a complete moron who clicks OK to everything he's presented with.

PANDORA'S BOX - DO NOT OPEN
Do you want to open?
[Accept] [Decline]

Re:No

[vlm]

If there is one thing we should all know is that trust cannot be inherited more than one step - your friend's friend's friend is as likely to be working for Cosa Nostra or RIAA (but, I repeat myself) as being trustworthy. Or he's a complete moron who clicks OK to everything he's presented with.

So in google+ language, you're saying use "Your Circles" instead of "Extended Circles". I'm not seeing that as being a technological blocker.

Re:No

[amorsen]

At some point, you're gonna have to trust someone else, and invariably that trust will be broken at some point. So, how do we fix us broken humans?

For instance you design the protocol so that e.g. 2 or 5 or however many you want humans have to be untrustworthy for the protocol to fail. Allowing multiple signatures on certificates would be a good first step towards that goal.

Re:No

[amorsen]

If multiple entities in your web of trust have to say that a particular certificate is ok, it gets a lot more difficult to forge a certificate.

Re:No

[Anonymous Coward]

The answer is using a shared language.

So we have a language that we all learn, so that we can understand each other.

We then translate critical thoughts which are at that point, secure in your mind, into whatever language we use and all understand.

Then you want to apply something after the fact, to prevent someone else from recovering what you wrote.

Why not just use a private language? Even statistical analysis won't work if they don't know what constitutes your language. And you STILL can apply all of today's technology to protect THAT copy. So what if they finally decrypt it after 2 years? Now they have ONE document to start figuring out. They need at least a few others to begin building information on your made up language.

Listen to how gangs talk. Each has their own words and symbols to convey messages which has really thrown law enforcement a curve ball. Now apply some intelligence above that monkey-thought and create a really different language and never record how it works.

Re:No

[arth1]

If multiple entities in your web of trust have to say that a particular certificate is ok, it gets a lot more difficult to forge a certificate.

Does it? A botnet that gains access to a WoT (due to one person being a moron) can easily change that -- suddenly 90% of your friend's friends say that cheap-rolex.in is a trustworthy site, and because the site is new, none says otherwise.

This isn't just a theoretical possibility - a famous spam vetting site was compromised this way, with hundreds of "users" marking spam as "not spam".

You can only trust what you can see with your own eyes; trust does not inherit, plain and simple. Any system that relies on inherited trust is broken before it starts.

Re:No

[Anonymous Coward]

Depends which government. The US government most likely wants to resolve bank.com to bank.com for its citizens. However, Elbonia wants to resolve bank.com to badsite.el for anyone outside its borders for obtaining accounts via phishing.

CAs need to be run by an international body that isn't beholden to one country's interests.

Re:No

[toastar]

Actually, that is a good idea.

The articles aren't really discussing absolute trust, they are talking about only one aspect of SSL -- identification.

A root CA doesn't tell me "you can trust example.com", it tells me that example.com really is example.com. The root CA supposedly put the effort in to making sure the domain owner provided supporting documentation to prove they are who they say they are.

This is analogous to what States do in requiring proving identity before issuing a driver's licenses. Or, as Federal Governments do before issuing passports.

We trust the governments with this function now. I don't see what the big issue is in trusting them with the digital version.

Wow that makes perfect since, and yet I still find somehow to completely disagree.

Re:No

[SmurfButcher Bob]

I have reservations about that concept, however. My fear is that the typical "web of trust" is going to evolve exactly like a "web of friends" on facebook, and be subject to the same pitfalls in one sense or another.

Re:No

[amorsen]

You can only trust what you can see with your own eyes; trust does not inherit, plain and simple. Any system that relies on inherited trust is broken before it starts.

Our whole society is reliant on inherited trust. Feel free to try to escape from it.

Re:No

[arth1]

So in google+ language, you're saying use "Your Circles" instead of "Extended Circles". I'm not seeing that as being a technological blocker.

It is a mathematical blocker, because there are far more web sites out there than your immediate circle has time to visit (or interest in visiting).

Just ask everybody you trust today whether they've ever visited diamonds-usa.com and think it's a trustworthy site.

Re:No

[chill]

Resolving is DNS, not SSL.

Short of proxying every external connection, transparently intercepting every SSL transaction and substituting the certificates on the fly, I'm not sure how what you're describing is possible.

Fraud and corruption exists virtually everywhere. International bodies are subject to pressure just as national ones are. If you think the UN is totally objective and doesn't respond to various national interests, I have a bridge to sell you in Brooklyn.

Re:No

[chill]

You have a healthy distrust of governments. That's a good think, but you shouldn't let it blind you. You just need to limit your trust to the minimum necessary to get the job done.

Corruption and the ability to misuse power isn't limited to government. The CDDB fiasco comes to mind, for one.

Re:No

[tepples]

What you are talking about corresponds to a constant secret key shared among a group. How is that better than a public/private key pair used to negotiate a secret key per session, which is what TLS uses?

Re:No

[Synerg1y]

They also can't say you used your driver's license to purchase alcohol at 10 PM on Saturday night, or whether you purchase it every Saturday night or just 3/4 for the month. Trusting the government with anything > less privacy because the government wants to know who it's helping. Thus why when filling out government forms, you may have indicate your penis/boob size to allow the government to help you more accurately -- soon.

I think Verisign has a bit of a monopoly going on right now, I'd be interesting in seeing google, MS, and anti-virus vendors contribute, except in an open standard that would allow them to cross verify.

Re:No

[ArsenneLupin]

Just ask everybody you trust today whether they've ever visited diamonds-usa.com and think it's a trustworthy site.

... and thus making useless to them any sites that you visited.

Congrats, you just proved brilliantly why a "web" of trust can't be trusted, even if it's only one hop "deep". Yes, I am aware that is actually the point you are trying to make, but you probably didn't intend to make in this way...

You may trust your friends' integrity and honesty, but you better won't trust their knowledge about what a certificate actually means.

Re:No

[F.Ultra]

Because when the government wants to snoop on a site they of course doesn't want the site to be encrypted with SSL so in that case they simply send you a phony cert and sign it with their root CA so your browser accepts it (if we let governments be the root CA:s). Granted, there are probably some NSA undercover organization on all browsers root CA list today, but still.

Re:No

[ArsenneLupin]

Does it? A botnet that gains access to a WoT (due to one person being a moron) can easily change that -- suddenly 90% of your friend's friends

This could be addressed by the WoT software making sure that most paths of trust are independent from each other, i.e. don't pass all through the same person.

say that cheap-rolex.in is a trustworthy site

... and this is the real danger! That almost nobody understands what the system is for, and issue certificates willy-nilly because they don't understand what they are for. And as misunderstanding about this whole CA and WoT business is rampant, you may indeed have more than one person who issues me an id card with Richard Stallman's name on it but my photo, simply because they think RMS is a trustworthy chap...

Re:No

[chill]

That isn't correct. They are regulating the sale of alcohol directly, though this is limited to local governments. It has absolutely nothing to do with your identification.

I understand being wary over the ever increasing demand for personal identifiers. I believe you're referring the Real ID Act. But I'm not advocating that the gov't take sole control of issuing online identities. I'd be happy to see the big boys in the game as well. Users could choose which of them to trust.

Hell, they can do that NOW. Feel free to delete the root CAs you don't trust.

Re:No

[chill]

What you're looking for is a Firefox Plugin called Certificate Patrol. It will let you know if a certificate changed since it was first seen.

So, if I've been using a certificate for Bank of America signed by Versign for the last year. (Work with me here. Assume Verisign isn't already a front for the NSA. :-) And all of a sudden the certificate changes to one signed by someone else, it'll warn me. Even if it is signed by the same CA, but the hash or signature changes, it'll warn me. Hell, you even get an extra warning if the certificate was renewed, but not close to expiring before!

As that paragon of virtue, Joseph Satain once said: "doveryai, no proveryai" Or as Ronald Reagan put it: "Trust, but verify."

Re:No

[shentino]

SSL certification isn't broken.

The economic system around it is broken.

Like many other industries, a lack of competition is what is wrong here. Verisign and others like them have a monopoly, and as such have no incentive to improve quality or lower costs.

Re:No

[cowboy76Spain]

At some point, you're gonna have to trust someone else, and invariably that trust will be broken at some point. So, how do we fix us broken humans?

For instance you design the protocol so that e.g. 2 or 5 or however many you want humans have to be untrustworthy for the protocol to fail. Allowing multiple signatures on certificates would be a good first step towards that goal.

Yeah, because there are only 4 humans in the world who you would not trust (either because they are bad people or naive enough that bad people can trick them).

I have a great news for you, I have started working that way and I can offer you two trusted CA certificate. First one is signed by 3,000 bearded guys (they like calling themselves Al Qaeda). The second one is even better, because it is from 100,000 cadres from de CPCh. Which one do you want?

Re:No

[arth1]

And as misunderstanding about this whole CA and WoT business is rampant, you may indeed have more than one person who issues me an id card with Richard Stallman's name on it but my photo, simply because they think RMS is a trustworthy chap...

Of all possible examples, that was a very hairy one to pull...

Re:No

[Altrag]

TFA's idea is that you choose who to trust, and you can revoke that trust at any time and replace it with someone else.

It then takes the step of saying "ok I'm going to look up the information from these 5 trusted guys, and majority rules".

Its definitely running under the assumption that you don't have a majority of your trusted authorities compromised at the same time (and in the same way -- if you ask 5 people at 2 agree and the other 3 are completely at odds from everyone else, chances are you're in a bad place. You might not even want to trust the 2, but you sure as hell don't want to trust any of the other three!)

So there's a few presumptions made:
1) Trusted authorities don't get compromised fast enough to have a majority of rogues.

2) Even if there are, the rogues are not cooperating.

3) When you do find a rogue, you revoke its trust in a timely manner.

This is a huge bloody list of requirements when you think about it. We've either got to (individually) maintain these lists ourselves, or trust a third party to do it. And guess what? As soon as you start trusting a third party, you're back to square one.

So I don't really know what they're fixing outside of a theoretical perspective. The vast majority of people (including website operators) in the world are going to be far too lazy to maintain these authenticity lists.

Now if they can come up with a secure, automated way to maintain the authenticity lists, then we'll be talking. Something like the way the eDonkey protocol has servers distributing lists of more servers so that once you've got that first server address, you quickly and automatically have large lists of other servers. Of course using that method directly isn't secure (it could be easily poisoned by a rogue server) but thats the sort of thing I'm thinking would be necessary to get any sort of large-scale adoption of a decentralized authority system.

Re:No

[datapharmer]

Short of proxying every external connection, transparently intercepting every SSL transaction and substituting the certificates on the fly, I'm not sure how what you're describing is possible.

Yep. How much bandwidth are you handling and what time do you need it installed by? Do you want it setup to transparently capture information from other sources using prefix hijacking at the border too? By doing so it is simple as pie to fake the authority and pass bad certificates that appear valid.

Re:No

[Kagura]

Hell, they can do that NOW. Feel free to delete the root CAs you don't trust.

This does nothing to help 95% of the web's users, who generally are worth protecting.

Re:No

[Kagura]

Because when the government wants to snoop on a site they of course doesn't want the site to be encrypted with SSL so in that case they simply send you a phony cert and sign it with their root CA so your browser accepts it (if we let governments be the root CA:s). Granted, there are probably some NSA undercover organization on all browsers root CA list today, but still.

It's doubtful that there are entire front CA companies in existence, but the CA sources are such high value resources that you can bet there are certainly hired agents who are paid to push mission-critical certs through.

Re:No

[Kagura]

Thank you! Installing now!

Re:No

[WrongSizeGlass]

I hadn't realized that my posts were heading in that direction (except for my comments about Aaron Barr), but looking back at them they do seem a bit angry lately (and some have gone a little too far). You're correct that I haven't been getting my usual sleep. I usually get 30 - 35 hours a week but it's dropped to 20 - 25 hours recently. I wish Einstein had figured out how to squeeze more hours into a day because I could really use them right about now.

Thanks for nudging me back on track.

Re:No

[Z00L00K]

That's a great idea for everyone from China to Syria.

Re:No

[Anonymous Coward]

Your link is broken. I've clicked accept like 15 times now!

Re:No

[Anonymous Coward]

Agreed. Does anyone have a solution?

I heard somewhere recently that a solution has been proposed... Oh yeah it was mentioned in the summary. Try reading it.

Re:No

[swillden]

It would be great to have SSL fixed but it won't happen. The reasons are (same as Flash, HTML5 and Java, IPV6): 1) has a monetary interest in the technology 2) The public/private sectors have adopted this as defacto standard 3) Haters hate change in the name of "secure"

The only way to change this is to implement a work-around which excludes the current 'key masters' and makes the previous technology obsolete (like HTML5.. ok, mostly obsolete).

Marlinspike's proposed replacement avoids that issue by making the change something that can be implemented on the user side without any action on the part of standards bodies or site owners. Really, the only players who have to implement the technology in order for it to work are the browser makers, and they can even make it optional.

Another aspect of it that I like is that it facilitates the use of self-signed certificates. Also, it's worth pointing out that his suggestion isn't so much a "replacement" for the CA system, but a stand-beside additional validation method. So for sites that use a CA you can get both checks. For sites with self-signed certs, you only get the Convergence validation.

Supposedly.

One problem I see is that the information provided on the Convergence web site is completely insufficient to understand how it works. The "Details" page doesn't really provide much. Here's my guess as to how it works:

• There are a set of servers scattered around the net which can be queried to validate a certificate. These can be run by anyone.
• The way one of these validation servers checks a certificate is (I think) by making a request to the site and looking at the certificate they receive from it. Perhaps they also check it against the certificate they've received from that site in the past, and perhaps the servers talk amongst themselves.
• Your browser has a list of such servers, and whenever you visit a site for the first time, it queries several (all?) of them to see if they got the same certificate from the site that you did.

Assuming my guesses are right, I think the core idea is clever and potentially very useful, but I see some flaws (which Marlinspike may well have completely addressed with his design -- but it's not clear how based on the minimal information I've seen).

• The approach defends against man-in-the-middle attacks unless the attacker has also compromised the link between the site being validated and the validation servers. This means that MITM attacks mounted "close" (in terms of network topology) to the user will be basically impossible (modulo the next point), but attacks mounted close to the site will be very likely to succeed. To make the security good, you also need to ensure that the client is using a well-distributed set of validation servers.
• The approach assumes that the client can trust its communications with the validation servers. This seems simple enough, though; when you configure a list of validation servers you also configure their certificates, much the same way you add a CA to your browser configuration. Then when the browser talks to the validation server it uses SSL and checks that the server cert matches the configured value.

Another issue that comes up is how to know what set of validation servers to use. Obviously users aren't going to configure this, any more than they configure their list of SSL CAs. The clear solution is the same one used for the CA list -- let the browser makers vet the validation servers and provide a default list, pre-configured. The user can alter it, but generally won't. If a validation server proves untrustworthy or unreliable, it can simply be removed in an update. Given the use of multiple validation servers, removing an untrustworthy one would be an important but not particularly urgent change. This is the "Trust Agility" Marlinspike speaks of... you can stop trusting someone who proves th

Re:No

[swillden]

Ugh. When did slashdot's formatting of lists get broken?

Re:No

[pnutjam]

Wow, someone responding like a real person in an online dialogue? Who says we aren't still evolving.

Re:No

[Eponymous Hero]

i, for one, welcome our new sleep-deprived, acrimonious over...

fuck, we need a new meme here.

Re:No

[WrongSizeGlass]

fuck, we need a new meme here.

Whatever it is, you'll have to do it after you get off of my lawn!

Re:No

[WrongSizeGlass]

Wow, someone responding like a real person in an online dialogue? Who says we aren't still evolving.

Well, I'm sure we all have at least one good post in us, but I think I recently used mine.

To quote Bob the Builder

[Anonymous Coward]

"YES, we can!"

Please use this thread to formulate your answers in a form of a questions. Thank you in advance for your contribution to the overall improvement of the Internet infrastructure and supporting the freedom of expression.

Re:To quote Bob the Builder

[Z00L00K]

Only if the scheme is that there's no third party involved being the CA.

CA = Man In The Middle.

But if one of the end points is CA at the same time then you have a reasonable security - provided that the CA certificate isn't spoofed when it's exchanged.

However - it also depends on the assumption that the encryption isn't cracked so that the private keys are exposed.

just allow anything.

[Anonymous Coward]

as long as the cert has the correct server name wtf does it matter if its self signed as long as the owner of the domain has signed it ?
use the public owner key which can be stored in a TXT record in DNS on the domain to verify.

Re:just allow anything.

[Chris Mattern]

as long as the cert has the correct server name wtf does it matter if its self signed as long as the owner of the domain has signed it ?

And how do you know the signature is the signature of the domain's owner?

Re:just allow anything.

[Anonymous Coward]

use the public owner key which can be stored in a TXT record in DNS on the domain to verify.

Re:just allow anything.

[jandrese]

Assuming the person doing a MITM attack against you is not modifying DNS queries as well?

Re:just allow anything.

[Lennie]

That is what DNSSEC is for.

But at the moment, no-one can garantee that if you are in a hotel network you can get that DNSSEC-information.

So it is hard to deploy at the moment, a good fallback-methode is needed to get it started.

Re:just allow anything.

[Z00L00K]

And how do you know that the Verisign (or whatever) CA certificate you have is authentic?

Re:just allow anything.

[Z00L00K]

Or if you are in a country that's chewing on the human rights - heck, almost every country can be on that list for what we know.

And some countries may even have the power to spoof the DNSSEC info.

Re:just allow anything.

[Lennie]

That is interresting, how would they do that ?

Maybe just for a country-level TLD like .de But not just any domain.

Bzzzt

[vlm]

The very best I could do would be to remove the offending CA's certificate from my trusted CA database, but then some large percentage of secure sites I visit would break.

Simple, almost trivial work around: Multiple SSL certs for a given host, not just the one true cert per ip addrs/host.

A bank or online stock trader is probably gonna have to cough up for ALL the majors. My current employer will probably continue to selfsign, at least for corporate webmail. Everyone else, somewhere in between.

I could see a requirement for PCI compliance you must get certs from at least 3 of this list of 40 providers, etc.

Re:Bzzzt

[amorsen]

Multiple certificates do not work today. You don't know which one you can present to the client. You need to extend the protocol to allow multiple signatures on the same certificate or allow the client to request a specific certificate. I don't like the latter option; the client should get to see all the certificates so it can notice if a major web site suddenly has only one signature.

Re:Bzzzt

[vlm]

Multiple certificates do not work today. You don't know which one you can present to the client. You need to extend the protocol to allow multiple signatures on the same certificate or allow the client to request a specific certificate. I don't like the latter option; the client should get to see all the certificates so it can notice if a major web site suddenly has only one signature.

Yeah, I know. But it seems a protocol extension is simpler than changing an entire industry.

It would make the firefox devs absolutely scream, but I'd like to see each cert from an ACCEPTED ssl ca have a little icon pop up in the "add-on bar". I would really like to see about 10 of those little icons when I'm trading stocks or online bank bill paying. amazon.com I'd like to see a couple. corporate selfsigned webmail, just a little corporate logo would be sufficient. Remote https access to my password protected personal home mythtv recordings collection, eh, my selfsigned smiley face will do. Access to /. via https, a little selfsigned cert with a goatse icon.. Hmm.

Re:Bzzzt

[amorsen]

Yes, I absolutely agree that multiple signatures are the way to go and that we need to get the protocol extended.

I think we even agreed in a previous thread :)

Re:Bzzzt

[Sloppy]

A bank or online stock trader is probably gonna have to cough up for ALL the majors.

If people did things right, those examples wouldn't need trusted introducers at all. No CA. When I opened my bank account, I had to go there in person and show my id. (And they had to put on a good show to convince me there were really "the bank" and not some fly-by-night con artist renting an office for a week.) Banks and their customers could be certifying each other.

I could see a requirement for PCI compliance you must get certs from at least 3 of this list of 40 providers, etc.

Actually, PCI would be a good opportunity to require that people do things right (see above). Make it so that a bank and a customer have to directly authenticate each other or else they're not compliant with common-sense best practices.

Furthermore, since we're twisting peoples' arms here anyway, require that the banks' signatures of customers identities, be shared with the public. Instant WoT upgrade, for the non bank world to use. :-)

(Governments would hate this, though, since it would lead to a secure Internet for the mainstream.)

Re:Bzzzt

[he-sk]

Access to /. via https, a little selfsigned cert with a goatse icon..

If you want to reduce your time spent on Slashdot, I'm sure there are less painful options.

Re:Bzzzt

[ArsenneLupin]

No CA...show my id

And guess who issued that id? A trusted third party, namely the government.

Re:Bzzzt

[Z00L00K]

https over https over https...

Every layer signed by a different CA.

The performance would get "interesting".

Re:Bzzzt

[Sloppy]

You've got a point. Governments: the ultimate CA. I'm ok with that, though. People use that same government ID to get through the rest of life, so even if it's wrong, it becomes correct, almost by definition. Mostly.

Possibly...

[dkf]

There is exactly one way for SSL certification to be fixed, and that's for browser makers to grow a pair and stop trusting root CAs who do not enforce strict rules for identifiability on all the lesser CAs under them. Yes, this will be painful as many legit sites will catch it in the neck for problems not really of their making, but anything else leaves CAs with an incentive to cheat; cutting violators off from the magic money machine is the only way of getting the crap out of the pool.

Re:Possibly...

[Medievalist]

browser makers to grow a pair and stop trusting root CAs who do not enforce strict rules for identifiability on all the lesser CAs under them. Yes, this will be painful as many legit sites will catch it in the neck for problems not really of their making, but anything else leaves CAs with an incentive to cheat; cutting violators off from the magic money machine is the only way of getting the crap out of the pool.

You're right, but disconnecting the problem networks was the obvious remedy for spammers and botnets, and we can see how well that worked out...

Asking any corporation to favor product or service quality is not going to fly if it puts them at a competitive disadvantage, and we have apparently abandoned the idea that government can assure a free and fair market through regulation.

Re:Possibly...

[mvdwege]

Doesn't help. You forget what SSL verifies: that the server you're connecting to holds the private key belonging to the certificate with the servername in the the DN. Nothing more.

If I register paypa1.com for my phishing operation and register a business in some Caucasian nation, I can cough up the papers that I am the righful owner of the domain. I am, according to your idea, completely identifiable. How are you going to stop Verisign from selling me a certificate?

Are you willing to give the power to vet domain registrations to yet another agency with a commercial incentive to not veto too much?

Mart

Re:Possibly...

[Darinbob]

Can we get multiple signers? Maybe we don't trust DHS to sign a lot, and we don't trust Chinese government to sign a lot. But what if they both signed something along with a third or fourth party? The whole point is to just say "yes, this really is the public key of the company you're interested in" so there should really not be any political issues involved with identification. The multiple signers means that it becomes that much more difficult to stick in man in the middle attacks or falsely sign a cert intentionally.

Right now if we have important legal documents they require multiple signatures. Such as a deed to a home signed by more than one person at a bank holding the lone, the new home owner, the past home owner, the title company, a notary public, and then it all gets filed with the county government.

Of course this falls apart with "trust agility". There are that many more signers meaning that many more links where you may want to break the trust. If you distrust any one of them then you distrust the whole certificate.

Re:Possibly...

[mdm42]

we have apparently abandoned the idea that government can assure a free and fair market through regulation.

Well, yes, because they have so clearly and repeatedly shown that they're up for sale to the highest bidder and completely incapable of doing what they're supposed to - acting as neutral and impartial adjudicator.

Re:Possibly...

[Medievalist]

we have apparently abandoned the idea that government can assure a free and fair market through regulation.

Well, yes, because they have so clearly and repeatedly shown that they're up for sale to the highest bidder and completely incapable of doing what they're supposed to - acting as neutral and impartial adjudicator.

True, but if you have a broken faucet it doesn't make sense to cap the well and start drinking your own urine.

Instead of saying "Our government is corrupt, therefore all government is evil and must be dismantled" it would make more sense to say "Our government is corrupt, so let's convict and execute the individuals responsible for the corruption". Fix the faucet, don't destroy the well.

But then again, most modern Americans are incapable of walking to market, much less getting off the couch and storming their local political criminal's headquarters. So perhaps we have ended up with exactly the government most of us deserve - fat, amoral and incompetent.

Won't happen.

[Anonymous Coward]

Not as long as there are Millions to be made.

Re:To quote 4chan

[Anonymous Coward]

"NO, it's fucked!"

At this point, short of whatever this software and proxy thing this guy is pushing being bundled with IE 10, Firefox 5, Chrome, and every other browser, plus as mandatory, automatically applied hotfixes to all other browsers all the way back to IE 6, plus utilities like curl, wget and so on (and I haven't even touched imaps/starttls for smtp and ftp/etc), the SSL certificate infrastructure cannot be replaced. Nobody is going to choose a cert that will cause most of the browsers to flip out, so they'll keep right on buying their certs from the authorities they already pay.

Now that secure DNS zones are starting to appear, stuffing the cert into a signed DNS zone comes up as an option, but this is just kicking the can: who is signing the cert for your zone in the first place?

Distribute Certificates via DNS (using DNSSEC)?

[SmilingBoy]

Wouldn't it be possible to verify the certificates via the DNS? Once that is secured with DNSSEC, this should be a very good solution. Or am I missing something?

Re:Distribute Certificates via DNS (using DNSSEC)?

[vlm]

Wouldn't it be possible to verify the certificates via the DNS? Once that is secured with DNSSEC, this should be a very good solution. Or am I missing something?

That DNSSEC is even worse of a single point of failure than SSL. Same type/class of problem, just worse.

If you thought the SSL providers were shady, you'll think them heroic princes of justice once you start dealing with DNS registrars.

Re:Distribute Certificates via DNS (using DNSSEC)?

[Anonymous Coward]

Yep. You are missing the first link in the article: http://blog.thoughtcrime.org/ssl-and-the-future-of-authenticity and the part where Moxie shares his thoughts on DNSSEC trust hierarchy...

Re:Distribute Certificates via DNS (using DNSSEC)?

[Anonymous Coward]

DNSSEC is fail in multiple ways. It's failure is even more epic than ipv6's. I've recommended my employer (isp/hosting) to NOT embrace this broken standard, and I know of several distinct problems which we have evaded. Same with ipv6 actually.

Re:Distribute Certificates via DNS (using DNSSEC)?

[CAPSLOCK2000]

I do not agree with you. DNSSEC does not make any claims about who owns/hosts a domain, it only proves that you get the information as intended by the owner of the domain. If you ask for kokakola.com, you'll get kokakola.com.
SSL on the other hand is supposed to be verified. If a certificate say "The Coca-Cola Company" you can trust that it is really that specific manufacturer of soft-drinks, and not a clever competitor. (obviously theory != practice)

In reality an SSL-certicate is only usefull for encrypting your connection to the server. If you drop the "verified" identity part it should be possible to spread SSL-certificates via DNS.

DNSSECs offerings are much more moderate than those of SSL, but the goods are real.

Re:Distribute Certificates via DNS (using DNSSEC)?

[Anonymous Coward]

DANE

Re:Distribute Certificates via DNS (using DNSSEC)?

[guruevi]

SSL does the same as DNSSEC. If SSL says kokakola.com, you'll get a warning if you're not on kokakola.com otherwise it works just fine.

The Coca Cola Company only appears in the so-called "Extended Validation SSL" which means some validation might have been done. It's the same as the badges of BBB on websites or the "No Hackers Here" icons. Doesn't mean unscrupulous dealers won't ever put those badges on their websites or someone with a bad BBB rating can't put it on but if you click through and ANALYZE the data, then you can make a decision based upon it.

People need to learn how to read, people need to learn what they are doing. SSL certificates are like the CarFax report when you go buy a car. Most dealers will give it to you if you ask for it, some unscrupulous dealers might not give you the right one, most dealers don't point out there are minor issues with the car even though the CarFax could be clean. The CarFax however doesn't reveal whether the dealer is good, whether there is special language in the sales contract or that you're going to get set up with a larger-than-expected car payment. The CarFax tells you nothing about the dealer, only that there are no (very specific major) issues with the car.

Re:Distribute Certificates via DNS (using DNSSEC)?

[vlm]

I do not agree with you. DNSSEC does not make any claims about who owns/hosts a domain, it only proves that you get the information as intended by the owner of the domain. If you ask for kokakola.com, you'll get kokakola.com.
SSL on the other hand is supposed to be verified.

Security depending on the weakest link of the chain, running SSL over DNSSEC means you'll only be as strong as the monopoly DNSSEC signer... You'll be much worse off than SSL. At least there is a small confuseopoly of psuedo-competitive SSL CAs, they'll just be a monopoly signer for DNSSEC.

The original post claiming you'll secure the SSL certs using DNSSEC, but using DNSSEC would lower the level of security not increase it, so...

Re:Distribute Certificates via DNS (using DNSSEC)?

[Anonymous Coward]

Yes, it is possible to do so. Lots of certificates could be delivered through DNSSEC, like email encryption certs, as well as SSL certs.

The problem with certificates is that people can't trust the companies we're supposed to trust with regards to said certs. One of the big SSL cert houses gave a signing cert to the U.A.E. Therefore, since they can sign, they could sign bogus SSL certs that would verify. I'm not saying that the U.A.E. is underhanded in anyway, but to give a signing cert to an oppressive regime...

Because so many attempts at security have been made and have failed, it's a difficult sale to sell security.

Re:Distribute Certificates via DNS (using DNSSEC)?

[vlm]

SSL does the same as DNSSEC

SSL does a lot more, dude, trust me.

The DNSSEC layer only verifies no one has altered the port 53 packets. So the name to address mapping is certainly whatever the admin configured. No MITM redirection attacks. At least, none between the DNS auth server and DNS resolver server... What happens on your WIFI between your client and its resolver is its own problem.

SSL layer encrypts the whole data stream. No MITM attacks, at least not easily (need to crack an entire CA, or at least steal the secret key). As an interesting side effect, if the name of the SSL cert doesn't match the name of the domain, web browsers etc are supposed to go bonkers.

Both are actually a little more complicated than that.

Re:Distribute Certificates via DNS (using DNSSEC)?

[AceJohnny]

Moxie Marlinspike, the author of Convergence mentioned in TFA, addressed that very problem in a post. Long story short: a DNSSEC system would worsen the rigidity and centralization of the current CA system.

Re:Distribute Certificates via DNS (using DNSSEC)?

[silas_moeckel]

I would disagree (not about registrars being shady) validating a ssl cert in dns makes as much sense as these domain only ssl certs (they just email the contact on the whois for the domain). If it's just something you put into your own DNS records your registrar has nothing to do with it. DNSSEC can protect those DNS records from mam int he middle attacks. You can even keep the CA's around for there extended verifications (what they said they would do in the first place then didn't then charged more to do but still don't). OpenID and other SSO type things is a better solution for keeping login credentials safe (well known site is the only place you log into it can use crypto keys stored in your browser), DNS based certs with dnssec protects from mitm attacks and you can still rely on the green bar ca bits for sites that take cc etc and think it add something. Most sites just want something that will not generate scary messages in there users browsers, few users care about green bars or even know what they are, DNS can get us that.

Re:Distribute Certificates via DNS (using DNSSEC)?

[arth1]

SSL layer encrypts the whole data stream. No MITM attacks, at least not easily (need to crack an entire CA, or at least steal the secret key).

Or install a root certificate on the user's machine.

Tightening up the SSL system would primarily be to help the casual users - us tech-savvy users have the means and inquisitiveness to actually check out a cert chain, and a healthy paranoia that stops us from installing malware, but these users won't. As long as they are easy marks for viruses and scams, tightening up SSL won't really help. Just remember how many users get infected with viruses, trojans and other malware.

There's no easy technological solution to what is a human problem.
Apart from a swift bullet to the neck, and that might be considered a bit too drastic.

Re:Distribute Certificates via DNS (using DNSSEC)?

[Anonymous Coward]

djb => http://dnscurve.org/

Re:Distribute Certificates via DNS (using DNSSEC)?

[Sancho]

The problem with SSL certs is that anyone can create them. People have gotten SSL certs for domains that they didn't own or have any control over. Any one of the numerous CAs might be subverted to provide a cert which will appear valid to any browser. The weakness in SSL stems from this--too many orgs are trusted by the browsers, too many orgs can sign certificates, and too much signing is delegated.

The fewer people you have to trust, the better.

Re:Distribute Certificates via DNS (using DNSSEC)?

[Anonymous Coward]

Basically he doesn't get it. His central arguments against DNSSEC based SSL keys are:
1) Can't trust the DNS registrars (he includes a GoDaddy ad hominem )
2) Can't trust the TLD operators (Verisign, corrupt governments)
3) Can't trust the root (ICANN)
Those are more or less the same argument, that we would have to trust DNS operators but shouldn't. That's bogus. You can get a properly signed SSL certificate today if you control a domain. The current system consequently doesn't add any trust over a completely DNS based system. The DNS based system on the other hand has one big advantage over the SSL CA hierarchy: There is only one possible path from the domain owner to the root. The Chinese government can't sign the DNS records for yourbank.com, but it can issue a certificate for that domain. DNSSEC-based SSL would therefore be more secure than SSL with CAs.

Re:Distribute Certificates via DNS (using DNSSEC)?

[vlm]

Or install a root certificate on the user's machine.

I wouldn't worry about preventing that attack vector... if you own the machine to that level, its easier to just install a keylogger, grab screenshots, trojan the webbrowser itself, rather than trying to MITM the machine. Unless its some kind of govt surveillance thing. Hmm.

Re:Distribute Certificates via DNS (using DNSSEC)?

[Anonymous Coward]

So the SSL system of 100+ points of catastrophic failure (e.g. compromise of *any* of the hundreds of CAs allows an individual to spoof every domain under all circumstances) is more secure than a truly single point of catastrophic failure with a hierarchical system which further limits the scope of danger if lower levels are compromised?

Additionally, it is worth noting that the current web SSL system is, as a matter of practice, already built on trusting the DNS system.
1) Domain Name System and Registrars are the primary system used to track who owns a domain
2) CAs are charged with validating you own a domain prior to issuing a cert, usually via dns records
If you want an ssl certificate for a domain, you just need to prove you control of the DNS records for that domain and... tada! any CA will give you a cert for that domain, since you proved you control it.

Re:Distribute Certificates via DNS (using DNSSEC)?

[tepples]

You can get a properly signed SSL certificate today if you control a domain.

But you can only use this SSL certificate if you control an IPv4 address. An HTTPS server needs to send the correct certificate before even seeing the Host: header, and Internet Explorer on Windows XP, Safari on Windows XP, and Android Browser on Android phones can't see any of the several certificates associated with an IP address other than the first. With hosting providers such as Go Daddy packing upwards of 1,000 name-based virtual hosts on one IP, controlling a domain alone isn't enough to allow use of HTTPS.

Re:Distribute Certificates via DNS (using DNSSEC)?

[Onymous Coward]

The current system consequently doesn't add any trust over a completely DNS based system.

So, DNSSEC is no improvement (in this regard)? I think maybe you're not disagreeing with Marlinspike. He says:

So unfortunately the DNSSEC trust relationships depend on sketchy organizations and governments, just like the current CA system.

But you say "The DNS based system on the other hand has one big advantage over the SSL CA hierarchy" in that, IIUC, you don't have a "mixed scope", i.e. multiple organizations who can vouch for any domain. He addresses this:

# There's a mixed scope. Some have suggested that the problem with all of this is the scoping. That the DHS shouldn't be able to sign certificates for Chinese sites or vice-versa. To me this seems like a low bar. There are plenty of people who don't trust the DHS to sign certificates for any sites, and restricting the Chinese government to Chinese sites doesn't feel like a particularly powerful win either. So I'm also skeptical that this is the essence of the problem. "

What you're calling a relative strength here is by itself not nearly enough to warrant the switch to DNSSEC.

Re:Distribute Certificates via DNS (using DNSSEC)?

[Onymous Coward]

Oh, and...

Can't trust the DNS registrars (he includes a GoDaddy ad hominem )

I can only assume you don't know much about GoDaddy. Not to be mean or uncharitable, but this example drives the point home. And please note that this also is not an "ad hominem" -- there's no fallacy in pointing out the poor character of a registrar when the trustworthiness of registrars is the argument at hand.

Re:Distribute Certificates via DNS (using DNSSEC)?

[evilviper]

No MITM attacks, at least not easily (need to crack an entire CA, or at least steal the secret key).

If I can change a couple lines in the whois info for your DNS record, I will have a valid SSL certificate (from a reputible authority) for your domain in a matter of minutes.

DNSSEC is better because all mistakes the certificate authorities can make are completely taken out of the equation, and you ONLY have to trust the DNS authorities.

Re:Distribute Certificates via DNS (using DNSSEC)?

[Anonymous Coward]

Marlinspike asks: "I mean really, do you trust this guy?" and links to a story about GoDaddy's CEO catching flak for going Elephant hunting in Zimbabwe. What relevance does that have to a DNS registrar?

Re:Distribute Certificates via DNS (using DNSSEC)?

[Anonymous Coward]

I think you misunderstood. The argument isn't that having control over a domain is sufficient for operating an SSL web site. It's sufficient for getting an SSL certificate. A DNS registrar (or the TLD operator or the root) can manipulate DNS, so they can technically get an SSL certificate for your domain through domain-based authentication. It is an absolutely trivial attack if your DNS registrar is also your hoster (GoDaddy).

Most of the SSL certificates in existence required no further authentication than being able to receive mail sent to one of a few names at the domain for which the certificate is issued. All players in the DNS game who could manipulate DNSSEC based SSL can already manipulate CA based SSL, and a heap of other entities can too.

I would agree that there is a need for a separate system which can provide more and most importantly independent trust. The point is that the CA hierarchy, for all the money that it sucked up, does not deliver on that promise. DNSSEC based SSL is at least as good protection against most men-in-the-middle as the current CA based SSL. I think it's even a little better, because it's basically free, so it can be used ubiquitously, and there are fewer organizations which can attack a given trust chain. Enabling ubiquitous SSL is a particularly strong point for DNSSEC based key distribution. If you can come up with something better, let's hear it. Until then, let's work on getting SSL key into DNSSEC.

Re:Distribute Certificates via DNS (using DNSSEC)?

[Anonymous Coward]

If you want an ssl certificate for a domain, you just need to prove you control of the DNS records for that domain and... tada! any CA will give you a cert for that domain, since you proved you control it.

Moreover they will probably not even validate DNSSEC for your updates. Maybe some of them will, but it only takes one CA that will not validate DNSSEC to ensure that SSL using existing CA infrastructure is less secure than certificates in DNSSEC.

Oh, and at least for the first few years browsers should verify the certificate both ways and present the information in such a way that the users know what to look for to ensure the highest security level.

Re:Distribute Certificates via DNS (using DNSSEC)?

[Anonymous Coward]

You can stay away from IPv6 and DNSSEC for as long as you like, though eventually it will mean you'll go out of business as the rest of the world moves ahead.

IPv6 is going to happen before DNSSEC. Once IPv6 has gotten enough momentum that the people who care about the future of the Internet aren't worried about that transition anymore, expect several of them to start pushing DNSSEC as the next improvement.

There are a few details to sort out with DNSSEC such as how to handle TTL in a way that cannot be replayed, how to deal with the records which are too large for UDP packets and could be used to amplify DDoS attacks, and how to avoid zone enumeration (NSEC3 helps a bit, but doesn't prevent it). None of these are showstoppers.

Re:Distribute Certificates via DNS (using DNSSEC)?

[jonwil]

Thats why you use DNSSEC to store a public key in the DNS record which is then used as part of a SSL negotiation with the legitimate server having the private half of the key.

Prevents man-in-the-middle attacks unless the hacker can make your client think that their hacked DNS record is validly signed through DNSSEC keys (or can somehow get a bogus record into DNSSEC directly) and also prevents eavesdropping because only the legitimate server has the private half of the key.

No need for CAs to get involved or for anyone to care who owns "www.paypal.com", all people need to care about is that they are talking to the legitimate server belonging to www.paypal.com and that the public key they are using is the one that matches the private half stored on the legitimate server belonging to www.paypal.com

Why the fuck should i need an authority ?

[unity100]

all i need is a key to encrypt my communication with. if i can do it with an openssl command on some local computer, none should need to pay anything to 3rd parties to use ssl certs on their servers.

no - i dont need anyone to 'verify' any domain. i dont buy from any sites i dont know and trust, and therefore third party intermediaries cashing in by selling me trust is totally unnecessary. not that it works at all though - even a megacorporation can swindle you through numerous means.

Re:Why the fuck should i need an authority ?

[Anonymous Coward]

i dont buy from any sites i dont know and trust

And just how do you know the site you're connecting to is actually the site you (think you) know and trust?

Re:Why the fuck should i need an authority ?

[Anonymous Coward]

i dont buy from any sites i dont know and trust

How will you know if it's a man in the middle, or not some imposter that hijacked the DNS entry for e.g. newegg?

Re:Why the fuck should i need an authority ?

[vlm]

Do you have a solution for MITM attacks? No? Well then.

Re:Why the fuck should i need an authority ?

[blueg3]

Or subverted a wireless network the user is on. Or published fake BGP routes that cause traffic to go through a node you control. Or any of the dozens of other fine ways to execute a man-in-the-middle attack.

Re:Why the fuck should i need an authority ?

[asdf7890]

You do need someone to verify the domain first time you access it unless you have some means of verifying it yourself. Otherwise you don't know that the server you are sending encrypted data to is the server you think it is. Without some form of verification (what we have now, broken as it is becoming, or some replacement system that is at least no more broken) anyone could create a server pretending to be amazon.com or yourbank.com, create a certificate saying that the server is the real one. All that is needed then is a DNS poisoning attack or other such and the data that you are sending is all nice and safely encrypted all the way to a server that you don't want to send it to. Now the owners of that pretend server can use you data to gain access to your accounts on the real servers and so forth.

Some verification system is absolutely required, so until something better is proposed, designed, implemented, tested and widely available we can't just drop the system we have now.

Re:Why the fuck should i need an authority ?

[bunratty]

For encryption to do its job, you need to verify that you're encrypting your communication such that only you and the party you intend to communicate securely with can decrypt the message. How do you know you're using the right key? Someone may have slipped you the wrong one. It's called a man-in-the-middle attack.

Re:Why the fuck should i need an authority ?

[lucidlyTwisted]

Indeed, and it will only get worse as non-ASCII gains traction.

Re:Why the fuck should i need an authority ?

[isorox]

Do you have a solution for MITM attacks? No? Well then.

Chances are you've visited the site before. If an ssh key changes, I get a stern warning when I ssh in.

On the offchance you've gone to a brand new site, from a non-trustworthy network, you could be subjected to MITM, but once you go to the site from another location and ISP you'll realise there's an issue.

Doesn't eliminate it, but certainly reduces the problem of local wireless MITM attacks. ISP level and above attacks will be noticed fairly rapidly by nerds that actually check certificates.

Re:Why the fuck should i need an authority ?

[guruevi]

Does SSL? No? Well then.

If you don't believe me:
- Anybody can create an SSL certificate for any domain given the right access and if you or your computer accepts a certain CA
- There are many in the list on your computer that you probably haven't ever heard of and aren't really trustworthy - my computer has AOL, GoDaddy, Verisign, several state-run from Turkey, Belgium, Netherlands, China, ... Visa, RSA (lost some of their keys recently), DoD - you're still not protected against any of them.
- Given enough resources somebody could find a collision with the root certificate. With current GPU clusters this seems to be a matter of years now.
- CA's that were trusted before might not be trusted now (ipsCA) but still their root certificates are valid until they expire.

Re:Why the fuck should i need an authority ?

[vlm]

Fair enough. I like your idea. Bootstrapping is a problem.

How about this for the bootstrapping problem: A charity like the EFF could host a verifier that would connect and verify the SSH key or equiv. A simple firefox addon could alert you if a brand new website you've never visited before reports a SSH key different than the one the EFF verifier reports.

Why would the EFF bother hosting an "introducer" service like this? Simple, the new company that wants new users to visit them, would donate a modest sum to the EFF... I generally speaking trust the EFF so I would trust their ssh keylist. Would I poll the EFF keylist? Yeah. Would I poll the godaddy keylist? Uhhhhh.. not.

To some extent this is just reimplementing the ongoing trust model problems of SSL CAs into a new introducer service.

Perhaps social networks could pull their own weight for once, and you could pool a ssh keylist from all your "friends" or G+ circle members or whatever.

Re:Why the fuck should i need an authority ?

[icebraining]

That's still orders of magnitude harder than being able to MITM by simply setting up Apache.

Re:Why the fuck should i need an authority ?

[bunratty]

At least SSL tries to prevent MITM attacks. The proposed scheme doesn't even attempt it or consider that they could be a possibility. I'm sure SSL could be improved, but just throwing your hands up and giving up trying to prevent MITM attacks isn't an improvement.

Re:Why the fuck should i need an authority ?

[vlm]

Does SSL? No? Well then.

Whoa there. Please review the entire concept of a CA root cert. I suppose on a meta-level someone could MITM a torrent download of your OS install, to replace the real verisign cert with their own, but...

Anybody can create an SSL certificate for any domain given the right access and if you or your computer accepts a certain CA

If you own the secret key of a public root key for a CA that is installed on the victim's PC, then yeah. Or, if you can force your own CA into a victims machine. Otherwise, not so much.

Re:Why the fuck should i need an authority ?

[Anonymous Coward]

[[Chances are you've visited the site before.]]

So, every new MitM attack will first start with a redirect...

Re:Why the fuck should i need an authority ?

[bigpat]

Encrypted communications are pointless without knowing if you are actually communicating with the server/computer you think you are. DNS or an IP address can't be trusted in the case where someone has some physical control over the communications infrastructure. To trust DNS or IP addresses is the same as trusting that no one can physically intercept/redirect your communication. Might as well send in clear text or just speak in pig Latin if it makes you feel cool.

That said if your own computer's security is compromised then you are hosed either way as the browser itself can be compromised.

Re:Why the fuck should i need an authority ?

[nahdude812]

If an SSH key changes, you know why or can find out, because you're connecting either to a device under your control, or under the control of someone you have the capacity to contact. This is not true if an SSL key were to change. If a major website had a data breach and decided they needed to revoke their SSL cert, then all of their customers would see a "Warning, this certificate does not match" message, and would have no way to know if it was because the key was legitimately changed, or if this is a MITM attack.

AKA: This is still no solution.

Re:Why the fuck should i need an authority ?

[spitzak]

See above comment about the browser complaining if the SSL certificate changes.

Re:Why the fuck should i need an authority ?

[Anonymous Coward]

This exists! More or less. The Projectives Project

http://perspectives-project.org/

There's a Firefox extension. You can have it automatically override sites with security errors.

Re:Why the fuck should i need an authority ?

[turbidostato]

"I generally speaking trust the EFF so I would trust their ssh keylist"

Maybe because it doesn't get a tip from a bazillion sites which would make the EFF an interesting target for greedy bastards.

Re:Why the fuck should i need an authority ?

[Terrasque]

How about this for the bootstrapping problem: A charity like the EFF could host a verifier that would connect and verify the SSH key or equiv. A simple firefox addon could alert you if a brand new website you've never visited before reports a SSH key different than the one the EFF verifier reports.

Also known as the Perspectives project.

To some extent this is just reimplementing the ongoing trust model problems of SSL CAs into a new introducer service.

That project tries to solve it by having many verifiers, and a certain percent of them have to match.

Re:Why the fuck should i need an authority ?

[Amouth]

but it will always complain on first visit - as it goes from unknow to known.. Your reliance on trusting if the cert changes rests on trusting the first cert..

Re:Why the fuck should i need an authority ?

[asdf7890]

That only protects you once you hve first accepted the certificate - it does not help first time you connect. You can't trust a certificate coming from some.domain.tld because it appears to come from some.domain.tld - the two things can not mutually verify each other.

Also it does not allow for any form of revocation, if the server and/or certificate becomes compromised, other than you manually revoking the trust. You could implement expiry as with current certificates (the system as designed has full revocation support too, though I don't know how well it is implement in reality) but then you are repeating the validation issue after each period.

You are proposing a system like used with SSH, but it only works if you have some other secure means of transmitting enough information to allow the identity to be verified. You might blindly accept the first certificate a server sends you when you first connect via SSH to, for instance, a web hosting account (most people do) but you would want better assurance than that for a banking related account. For instance the banking people I work with in my day job transmit the server fingerprints to us by other means so we can verify any new server we may need to connect to, and we do the same for when they need to open connections to our services - you would want to be that careful for your own personal information too.

Re:Why the fuck should i need an authority ?

[tepples]

[Perspectives] tries to solve it by having many verifiers, and a certain percent of them have to match.

If the MITM is between a server and its only connection to the Internet, all verifiers will see the same MITM's certificate.

Re:Why the fuck should i need an authority ?

[evilviper]

Actually, I'm with the GP. All SSL has ever told us, and all that DNSSEC will ever tell us, is that you're talking to a guy who controls the DNS record... Your registrar, or anyone along the chain could change your whois data, and get a valid SSL certificate issued to themselves, or could change your DNSSEC info and redirect you to a new server.

It's much more agile if everyone is their own registrar. You need to somehow verify the organization is legit before submitting your data to them, but SSL and DNSSEC certainly won't do this, so it's nearly worthless. Once you've decided to accept a self-signed certificate, any other organization taking control of that domain will NOT be able to pretend they are the previous people, because their self signed or purchased cert doesn't match.

A different authoritity for each domain, and we're all better off. Yes, you have the problem of verifying the key for each new site, but at least we're not pretending that DNS control proves your are who you say you are.

Re:Why the fuck should i need an authority ?

[jgrahn]

Do you have a solution for MITM attacks? No? Well then.

Chances are you've visited the site before. If an ssh key changes, I get a stern warning when I ssh in.

I sometimes think the problem with crypto is the ultra-paranoid people who want all or nothing. This is a good example: unless you somehow verify the ssh host key the first time you interact with a host, you don't *really* know that the NSA isn't listening in or modifying what you see ... but on the other hand it's completely trouble-free, decentralized and easy to understand!

I've tried to use OpenPGP for mail, but the problem is noone is interested in implementing just *decent* security; it's full paranoid mode and usability suffers. (And of course at the same time it's as vulnerable to a local root kit as anything else.)

Re:Why the fuck should i need an authority ?

[Anonymous Coward]

epic basic crypto knowledge fail, and who the fuck modded this shit insightful? You need a trusted third party to prevent man-in-the-middle attacks.

Re:Why the fuck should i need an authority ?

[Anonymous Coward]

Chances are you've visited the site before. If an ssh key changes, I get a stern warning when I ssh in.

On the offchance you've gone to a brand new site, from a non-trustworthy network, you could be subjected to MITM, but once you go to the site from another location and ISP you'll realise there's an issue.

Doesn't eliminate it, but certainly reduces the problem of local wireless MITM attacks. ISP level and above attacks will be noticed fairly rapidly by nerds that actually check certificates.

Um, excuse me, but SSH's system is horrible for more than a few servers and more than one admin. It would not scale at all to WWW scope. For more than a dozen or so servers, SSH should be doing a chain of trust model with a root key distributed with new OS installs. What do you think admins do when a server SSH keys changes, assuming they had already been there?

"hey (team of X people distributed over god only knows what) has server foo been cloned, rebuilt, repaired, etc? Can someone physically access the server and verify this key fingerprint for me?"

OR

vi .ssh/known_hosts :1021
dd

Re:Why the fuck should i need an authority ?

[Anonymous Coward]

Assuming that you have DNSSEC available, you could just publish your certificate (or fingerprint, or something) in there. You use DNSSEC to verify the DNS records, and the DNS records to verify the server's SSL certificate.

Something like this seems to have been implemented in Chrome:

http://www.imperialviolet.org/2011/06/16/dnssecchrome.html

I have absolutely no idea if this is a good idea though, or what tradeoffs this might have (apart from being incompatible with everything except Chrome). Still, it seems like a good start, especially if you only need to verify ownership of the domain and that the connection is going to the right server.

Re:Why the fuck should i need an authority ?

[mvdwege]

How many years of users just clicking away warnings have we had now? Let me put it strongly: throwing up a warning is not a security solution.

Mart

Re:Why the fuck should i need an authority ?

[Anonymous Coward]

Whoa there. Please review the entire concept of a CA root cert. I suppose on a meta-level someone could MITM a torrent download of your OS install, to replace the real verisign cert with their own, but...

Those actually get delivered via web browser updates, not core OS updates. Although on Windows (and Mac) it might appear part of the OS update because IE (or Safari, respectively) updates get delivered at the same time.

Which is why you didn't have to reinstall or patch up your OS when RSA had to reissue all their keys last spring... you just got updates for the browsers. You can actually just open your browser up and directly add/remove CA's as you desire, which is something I myself always do- I refuse to put China and a couple other CA authorities in my list. I'll deal with the "SSL Cert Warning" popup on a one-by-one basis if I need to visit any sites which rely on those CA's.

If not SSL, then what?

[Anonymous Coward]

Are there alternatives to SSL for HTTPS? If so, what are they and how supported are they? I'm no fan of SSL, but I'm much less of a fan of plaintext channels.

Re:If not SSL, then what?

[fuzzyfuzzyfungus]

Are there alternatives to SSL for HTTPS? If so, what are they and how supported are they? I'm no fan of SSL, but I'm much less of a fan of plaintext channels.

The problem isn't really with the math(I'm not ruling out specific implementation flaws, or future cryptographic research work; but that is overwhelmingly the least broken part of the system); but with the rather tragicomedic state of the measures in place to prevent impersonation by men in the middle, registrars fucking up/being co-opted, users being morons(Yes, Virginia, there is a difference between a lock icon in the address bar and a .gif of a lock on the webpage...) and so forth.

If you've already verified the certificate of the host you'll be chatting with by some out-of-band means, you are pretty much good to go: your communications will be impractical to eavesdrop upon, and nothing short of breaking into the host, by physical or electronic means, and grabbing the private key will allow impersonation by hostile entities. The sticky problem is the (overwhelming majority of) cases where you haven't or cannot verify the certificate ahead of time/out of band. Our present answer of "Well, just trust any one of an alarming number of not very competent entities to vouch for them" is pretty weak.

Make CA's more liable

[Animats]

There is exactly one way for SSL certification to be fixed, and that's for browser makers to grow a pair and stop trusting root CAs who do not enforce strict rules for identifiability on all the lesser CAs under them.

Right. CA's are supposed to be financially liable if they issue a cert to a party other than the one they're certifying. Part of the problem is that CAs get to write their own "relying party agreements". We need a tough, standard relying party agreement with a minimum guaranteed liability to get into a browser's approved root cert list.

Once in a while a CA will slip up. Then they pay. That keeps them honest. A CA is an insurance company, and should be regulated as such.

Re:Make CA's more liable

[Stellian]

financially liable

But why take money only when they screw up, when you can abuse your market position to ask for the maximum amount of money in the beginning, if they want to be in your root ? You are not making any extra money if they are competent, so why bother?
Ah, the joys of free market.

Re:Make CA's more liable

[pseudorand]

> Right. CA's are supposed to be financially liable if they issue a cert to a party other than the one they're certifying.

But the authenticity of a server is dependent on the handling of the private key by whoever runs the server. And CA's have no control over that. So if financial liability were actually enforced, no one would dare be in the CA business.

And yes, the agreements could have clauses about compromised keys not being the CA's fault, but we'd get in to all sorts of hard-to-prove-in-court stuff and waste a lot of money on lawyers instead of spending it on real computer security.

I agree that browser makers need to both cooperate and grow a pair and blacklist CAs found to have issued bad certs, but this has to be done just enough to scare webmasters away from using disreputable CAs. And then we can't all complain about the CA Mafia when we're all forced to use Verisign at $399/year.

But it's a too late for that anyway. Browser makers already threw up the SSL roadblocks before fixing the other SSL issues, so users have already been trained to click through them, so SSL is probably truly dead. And worse yet, nothing can take it's place, because users already know to just click through whatever shit the browser throws at them to get to their content. The internet is filthy and anonymous and there's no fixing it.

Re:Make CA's more liable

[ArsenneLupin]

A CA is an insurance company, and should be regulated as such.

This might work when you can put a clear price-tag on a breach, but this is rarely the case.

Just imagine the Syrian government eavesdropping on a protester's private facebook communications via a forged certificate, and using the intelligence gained to arrest and torture the protester. How could any money paid by an "insurance" compensate for this?

Two problems here

[PPH]

1. Prevent MITM attacks. Query several notaries and make sure that they fetch and deliver the same certificate you got. OK, I'll buy this. But:

2. What about a lazy CA that issues a certificate for an evil, look alike site? If the notaries are requested to fetch that certificate, it will be the same as the one I got. If you get diverted to an evil twin site and check its certificate, it will appear as valid.

I like the concept of trust agility. There should be several methods of authentication in play at any time. And if we can incorporate some principles from neural nets, your system should be able to change the trust weight it assigns each method dynamically based on some learning algorithm. So if one CA/notary/whatever screws up a few times, they get knocked off the bottom of your stack.

Re:Two problems here

[sunderland56]

Prevent MITM attacks. Query several notaries and make sure that they fetch and deliver the same certificate you got. OK, I'll buy this.

What if the wifi router at your local coffee shop is the 'man in the middle'? Then he can tweak every copy of the certficate you get.

Re:Two problems here

[SiriusStarr]

Your communication with the notaries is encrypted, however, which would prevent any editing of the returned certificate, assuming that the encrypted channel to the notaries is secure. Of course validating those keys is still a problem, but since they appear to be distributed with the program in the case of Perspectives, they can't really be hijacked, unless your initial download/install of Perspectives was intercepted, which should be able to be reasonably secured.

Re:Two problems here

[icebraining]

You'd still have a local copy of the notaries' certificates, just like today, so the MITMer can't touch their response.

Re:Two problems here

[ags1]

1. Prevent MITM attacks. Query several notaries and make sure that they fetch and deliver the same certificate you got. OK, I'll buy this. But:

How do you know your talking to the notaries and not the MITM pretending to be the site you want and the notaries? Maybe we should have notaries to check the notaries. But then how do you prevent those notaries from... we'll do it once more and everything will be ok. If the MITM controls the router/DNS/firewall/network/proxy/etc you used to access the internet the MITM might be the only one you can talk to. You could distribute the notaries certs with the browser so that they can't be MITMed... aka SSL.

Re:Two problems here

[vlm]

2. What about a lazy CA that issues a certificate for an evil, look alike site? If the notaries are requested to fetch that certificate, it will be the same as the one I got. If you get diverted to an evil twin site and check its certificate, it will appear as valid.

Theoretically the current CA system gathers enough contact data to serve the fake guys with legal papers, maybe more. That is a hole in the "sorta like sharing SSH host keys" solution.

Re:Two problems here

[PPH]

Which coffee shop? I move around a lot and, if I compare the notaries public keys with a copy I stored from the last coffee shop, and they differ, I'll know something's up.

A learning system (along the lines of a teachable neural net) could not only assign lower weights to suspect notaries, it could learn about security threat levels at different coffee shops.

Re:Two problems here

[MadMaverick9]

but then you're just going around in circles - right?

how do you know you can trust the cert of the notary who serves the cert of the notary?

shouldn't trust only be between the user and the actual website? no third party involvement whatsoever. by for example the website posting its fingerprint someplace on its site and the user verifying it.

then the mitm would have to do dpi if it wanted to modify the fingerprint served up by the website. is that likely or not?

Re:Two problems here

[js_sebastian]

Prevent MITM attacks. Query several notaries and make sure that they fetch and deliver the same certificate you got. OK, I'll buy this.

What if the wifi router at your local coffee shop is the 'man in the middle'? Then he can tweak every copy of the certficate you get.

No. Communication with the notaries is encrypted. The public keys of the notaries that you choose to trust are the root of trust for this system.

Re:Two problems here

[ags1]

a) How do you distribute the fingerprint? The MITM controls the network access, they can give you fingerprints that matches the fake cert that they are serving up. (rewriting web pages on the fly is easy, simple search for old fingerprint, replace with fake fingerprint) You're left with "out of band communications" like the phone network or snail mail. Something the MITM can't control. I don't really want to make a phone call to make a secure web connection. b) How do you get the user to make this verification? You tell most users to verify the finger prints they will look at their own hands. SSL is sound... the problem is the implementation of SSL. We have way too mean certificate authorities. We should have no more then 5. If they screw up, ie getting hacked, issuing a cert to someone who isn't who they say they are, etc... they get massively fined and on the second offense the lose their status as a CA.

MITM when accessing the notaries?

[Anonymous Coward]

If someone hacks the router to my network, then they will be able to intercept the communication when I query the notaries. Most MITM attacks are done close to either end of the communication and not on the backbone. I don't see how this would fix the problems as the expectation is that whoever is eavesdropping is doing it at either end, in which case they would either intercept my communication with the notaries or the communication between the target and every notary.

Re:MITM when accessing the notaries?

[amorsen]

Storing and updating the certificates for a small number of notaries is a lot easier than doing it for millions of sites.

"proposing a replacement"??

[bigpat]

Must have missed the part that actually proposes a replacement. Article disses DNSSEC (probably rightly) as being just more complicated than SSL/TLS , but not really any better architecturally.

Seems SSL/TLS does the job pretty well for what it does, at least from an architecture standpoint, it is just a shame that browsers only recognize (by default) only certain trusted certificate authorities, which introduces a third "trusted" party into your two-party communications.

Cutting out the third party (or parties) trust hierarchy would leave you vulnerable to man in the middle attacks, so it is hard to see a way around certificate authorities or something basically identical. DNSSEC, might make sense from the perspective of the same companies providing dns also providing a inline method of verifying that the name of the host matches the certificate and distributing that over the existing DNS infrastructure. Assuming some hierarchy of trusted DNS. But really this would be more of a process improvement, for one stop shopping for DNS and certificates with perhaps some distributedness of the actual certificates to make it a bit more resilient, than anything else more fundamental.

Is SSL/TLS really broken in a way that can be fixed? Or is it the nature of the problem that is the problem?

Re:"proposing a replacement"??

[m50d]

The only really different effort I've seen is Monkeysphere, which uses the openpgp web of trust to authenticate a site's SSL cert. Haven't heard much about it lately though, and whether it's any better is a matter of opinion.

Re:"proposing a replacement"??

[Anonymous Coward]

Must have missed the part that actually proposes a replacement

Yep, you missed it alright. It's called convergence, and it's linked to in the article.

http://convergence.io/index.html

Re:"proposing a replacement"??

[Anonymous Coward]

Instead of having DNS validating the host matches the certifcate why don't we simply have it say which CA(s) that the domain uses? So in my DNS for borkborkbork.com I could have have it say that I use Entrust and Verisign to sign my certs, if you see anyone else signing it don't trust it. Very much like we do for identifing the mail hosts we use.

That would get rid of at least a bunch of the issue and wouldn't require any changes to DNS or the CA infrastructure. Browsers and other systems that use SSL would need to add in a DNS check but that could be phased in over time.

It would still leave the fact that you shouldn't trust unknown sites even if they have the pretty little lock but thats not an issue I think we can solve through technology.

Re:"proposing a replacement"??

[Anonymous Coward]

The solution, which has been discussed, is to have some easy way to get additional cert from your trusted provider. The last thing I heard on it was to use a single or multiple QR code to transfer the cert to your phone, which, when you return home, transfers the cert to your computer which makes it available to the browser. Certs and CA is really something that should be handled at the OS level (IPSEC, anyone) rather than installed into the browser anyway. But that's a different story. Those of us around for the beginning of it in the Netscape era know that it was just security theater to get people using the web and we'd "come up with something better when we needed to"......... and we haven't.

Re:"proposing a replacement"??

[js_sebastian]

Must have missed the part that actually proposes a replacement.

It's in the second link, which is the one that's actually about the blackhat talk, rather than a 4 month old article...

Re:"proposing a replacement"??

[bigpat]

Ah thank you, I looked for a new article on the blog itself about the proposal and couldn't find any update as the slashdot teaser said.

Interesting solution. Still has problems like SSL/TLS, but a trust network might be no worse than the existing system which relies on paying certificate authorities, the cost really is holding back encrypting things like email or other point to point communications between individuals using computers. Not sure the point of an anonymous proxy though, since that implies you control the communications infrastructure which means an adversary still knows its you or someone in your network, seems like the level of anonymity and untraceability should be a seperate concern. Probably best to role this out for individual communications though, because e-commerce banks and others are probably okay with paying for a certificate from an authority. Get Google on board.

Re:"proposing a replacement"??

[Anonymous Coward]

I think they put the wrong link on the article.
http://convergence.io/ is the proposed replacement.

Re:"proposing a replacement"??

[Morty]

The correct solution to all this is to move certs to DNSSEC or some other DNS-based approach. If you combine several facts about SSL, it should be obvious why a DNS solution is correct:

(1) SSL is about tying certificates to hostnames. Your browser (or other SSL client) connects to an SSL server at some hostname H. The server responds with public key X. The job of SSL's authentication component is to verify that public key X is really owned by hostname H.

(2) The only information anyone has about who owns which hostname is the information associated with DNS records and related whois registry.

So TFA's concerns about not trusting DNS registrars, and wanting trusted notaries misses the point. Even if your DNS registrar is Joe the Used Car Salesman, and your notary is the Pope, how does the notary know who the server really is? Why, the notary has to look into the databases provided by the registrar! So if any notary has to rely on the registrars' data, how can the notary ever be more trusted than the underlying registrars? Any process more complex than somehow relying on the DNS registrar is security theatre. The DNS registrar creates your DNS identity, so is in the best position to authenticate it.

Put differently, if an untrusted entity can mess with DNS registration data, that same entity is in a position to convince any notary of their DNS identity. No process, no matter how convoluted, can fix this.

[I'm about to give up a mod point. Feh]

No

[sl4shd0rk]

It would be great to have SSL fixed but it won't happen. The reasons are (same as Flash, HTML5 and Java, IPV6):
  1) has a monetary interest in the technology
  2) The public/private sectors have adopted this as defacto standard
  3) Haters hate change in the name of "secure"

The only way to change this is to implement a work-around which excludes the current 'key masters' and makes the previous technology obsolete (like HTML5.. ok, mostly obsolete).

Well. The answer is simple.

[drolli]

If security is very important to you, then hand-pick the CAs you trust. Thats like in real life. Normally its probably enough to look at the drivers license to check who is in front of you, however dont rely on that if you need extra security.

Re:Well. The answer is simple.

[amorsen]

It doesn't work. If a web site you need uses a CA you don't trust, you're screwed. Unless you can get through to major banks and governments and tell them who to buy their certificates from...

Which is why we need to allow multiple signatures, so you can remove trust from a bad CA without losing access to major sites.

Re:Well. The answer is simple.

[turbidostato]

"It doesn't work. If a web site you need uses a CA you don't trust, you're screwed."

No you aren't. You just need an off-band method you deem secure enough to get the public CA key in question (i.e.: fax it).

Unless you don't trust such a CA for a reason. But if that's the case, why would you trust a cert signed by it anyway?

Re:Well. The answer is simple.

[drolli]

Ahem, am i screwed because my browser issues a warning to me? Or should this the big red sign be enough to inform me that i should not enter account information or confidential email there?

If its important enough to me, then i can verify the fingerprint of the certificate myself.

Re:Well. The answer is simple.

[amorsen]

Ok, so you're on the road and you access your bank. You get a warning that the certificate is untrusted even though you previously let the browser save the certificate. Now there are two options: Either the bank changed the certificate or you're hitting a man-in-the-middle.

Re:Well. The answer is simple.

[drolli]

Call your bank and ask them to use a trustworthy CA.

IMHO thw browser should ask you when started the first time which organizations should be trusted to, with a brief explanation and the number of certificates singed by this organization.

Re:Well. The answer is simple.

[m50d]

Maybe I trust the specific MyBank certificate because I've confirmed it directly with MyBank. But MyBank happened to go with ShadyCA, and I don't want to trust ShadyCA's root certificate in general. Browsers do not make it easy (is it even possible?) for me to trust just the MyBank certificate and not the ShadyCA root.

Re:Well. The answer is simple.

[turbidostato]

"Maybe I trust the specific MyBank certificate because I've confirmed it directly with MyBank. But MyBank happened to go with ShadyCA"

What's the problem, then? You just delete the ShadyCA public certificate and go to your bank site. Your browser will tell you that the certificate is not signed by an authority of confidence (which it isn't) and will allow to inspect the signature to see if it matches with what you have registered.

Could it be more straigthforward? Of course yes, it's workable as is? Yes too.

And, on a side note, maybe you should question yourself that if your bank is so careless as to go with a shoddy CA where else is it being careless without you noticing.

Trustability rating ?

[Anonymous Coward]

How about settings how much you trust a CA ? Would be arbitrary though ...

Self Signed certs + fingerprint

[roman_mir]

Do you know what a major PITA it is to deal with the insane browser policies that treat self signed certificates as if they are a terrorist organization, while giving a complete pass to the http based authorization with clear text passwords?

Bloody hell, what is wrong with this picture, where a self signed cert is actually presented as some form of a VIRUS almost to the end user, when all that is needed is a warning that there is a self signed certificate in the address bar, with an ability to mouse over to copy the fingerprint and compare it to a fingerprint found on a site or on a business card or email, etc?

How about making it easier for the web to adopt https in the first place by showing some humility and not behaving like total assholes on the part of the browser development/management teams and realize that majority of the sites that could use encryption for data transfers, especially where it concerns privacy matters, like user names / passwords, and rework the interface notifications that warn the users about self signed certs to something that doesn't look like a bomb is about to go off?

Re:Self Signed certs + fingerprint

[Spad]

The browsers were made to behave that way precisely to prevent the problem of people self-signing certificates for paypal.com or mylocalbank.com and browsers *not* making it obvious to the user that the cert probably wasn't valid.

Of course, you might argue that SSL certs shouldn't be relied on for identification, but that's what users have been told to do; look for the little padlock, make sure it says "paypal.com" etc.

Point is, reverting the behaviour would alleviate one problem while exacerbating another - mostly likely more substantial - one.

Re:Self Signed certs + fingerprint

[roman_mir]

As I said, browser can clearly identify that a certificate is self signed, not pretend that a virus is attacking the computer from a site that the user is navigating to, and provide a fingerprint to compare.

NEVER MIND 'the little padlock', don't even show it for a self signed cert! Just don't make it look like the site is an attack on the user!

Re:Self Signed certs + fingerprint

[spitzak]

Of course, you might argue that SSL certs shouldn't be relied on for identification, but that's what users have been told to do; look for the little padlock, make sure it says "paypal.com" etc.

THEN DON'T SHOW THE PADLOCK FOR SELF-SIGNED CERTIFICATES

My god, you people are so incredibly stubborn. You will repeat this "reason" over and over and over and over, no matter how many times people like me point out the TRIVIAL way to completely fix your objection to self-signed certificates.

Re:Self Signed certs + fingerprint

[bunratty]

Yes, a browser could do that. But then the browser would not be protecting against a real man-in-the-middle attack. I suppose a computer could also accept any password you type, but then it also would not protect against intruders.

Re:Self Signed certs + fingerprint

[roman_mir]

a sane, not a bought browser WOULD do that. It would NOT pretend that a self signed certificate is more dangerous somehow than plane HTTP and would just encrypt the traffic, show an icon for a self signed certificate where the fingerprint could be looked at and wouldn't show a 'lock' or whatever.

The sane and not a corrupt thing to do would be to encrypt the traffic with the self signed certificate, allow the user to check the fingerprint and not scare the user with insane alerts.

Re:Self Signed certs + fingerprint

[bunratty]

But then it wouldn't be protecting against man-in-the-middle attacks, just as a computer that let you type in any password wouldn't protect against intruders.

Re:Self Signed certs + fingerprint

[bunratty]

There isn't any objection to self-signed certificates. It's just that when a browser encounters one, it cannot tell whether that's a legitimate certificate or one from an impostor attempting a man-in-the-middle attack. That's why the browser throws up a warning -- to warn the user of a potential man-in-the-middle attack. Go ahead and use self-signed certificates. Just don't expect a browser to accept it without warning the user, because then the browser wouldn't protect against a MITM attack.

Re:Self Signed certs + fingerprint

[spitzak]

The complaint is that the browser does NOT throw up a warning for a completly plain page with no encryption (which I hope you will admit is even more suspectable to a MITM attack, seeing as the MITM can insert himself after communication has been started!). Therefore to the user, the worst security looks better than moderate security. This is stupid and should be fixed.

EVERY TIME somebody suggests this, some doofus says "but people will see the lock and think it is secure". These idiots either do not realize, or (I think more likely) REFUSE to realize that the browser needs some rewrite to remove those stupid warnings, and thus it is easy for the browser to also be rewritten to stop showing the lock! I'm getting pretty disgusted with the refusal to even pretend to understand opposing arguments. Hey, maybe there is a real objection, but I have yet to see one, and after years of this the arguments for those warnings still act as though it is physically impossible to remove the lock icon if SSL is used.

Re:Self Signed certs + fingerprint

[bunratty]

Oh, so every browser should throw up a warning for every page with no encryption? That's so dumb, I don't even know what to say!

Re:Self Signed certs + fingerprint

[spitzak]

I find it hard to believe you do not understand. Are you purposely trying to not get it?

What I and thousands of others want is for the browser to NOT put up a warning for self-signed pages. It also should not put the lock icon on the url.

Re:Self Signed certs + fingerprint

[bunratty]

Oh. So when someone launches a man-in-the-middle attack against me, I have to realize that little lock isn't there before I enter my password? I think I may not notice that. I would prefer a big dialog that warns me of a potential man-in-the-middle attack that I can't easily click past. Of course, that means that I'll get that for a self-signed page. Big deal. I just accept the certificate and never see the dialog again. I stay safe and I'm barely inconvenienced.

Re:Self Signed certs + fingerprint

[spitzak]

You don't get a warning for a plain http page, where the MITM has a really easy job to steal your password. So I see no reason for you to worry aboiut the MITM doing the enormously harder job of having been there on every single instance and interrupting every single communication since you first contacted this site.

Unless you can come up with an explanation of why a plain http page is safer than a self-signed certificate, none of your arguments make sense.

Re:Self Signed certs + fingerprint

[roman_mir]

who is CLAIMING that it would protect against MITM attack? WHO is claiming it?

Is plain text authentication over HTTP protecting against MITM attack? Does anybody think so? Is plain HTTP treated like a virus by the browser? Is browser throwing a fit when a plain HTTP site is requested?

Also, are you saying it's impossible to have MITM attack when a cert is not self signed, but is signed by a CA? Are you for real?

Anyway, once again: nobody is claiming that a self signed cert prevents a MITM attack. The question is: how much are the browser development teams paid by the CAs to make HTTPS with a self signed cert look, as if the sites with them are attacking the user?

--

Again, a non-corrupt way to deal with self signed certs is to show an icon that this site has a self signed certificate, so that placing a mouse over the icon would immediately display the fingerprint, which could be compared to a known fingerprint (preventing the MITM attack BTW).

Also why aren't browsers displaying fingerprints for certificates that are CA signed if one places the mouse over the 'https' portion of the address? Isn't that a silent confirmation of CAs, saying they can't participate in attacking you? Please. This entire argument has nothing to do with technology, but is a perfect illustration of corruption.

Re:Self Signed certs + fingerprint

[bunratty]

A MITM attack does not mean "having been there on every single instance and interrupting every single communication since you first contacted this site." The MITM happens only once. When it does, you get a warning about it. Because accessing a plain HTTP page cannot detect a MITM attack, you do not get a warning for it.

Re:Self Signed certs + fingerprint

[bunratty]

No, plain text does not protect against a MITM attack. That is why we have SSL. I have no seen anyone say it's impossible to launch a MITM attack with a certificate that is verified, but it's much harder. All encryption can be broken somehow. That doesn't make it useless. The point of encryption is to make it harder to make attacks, not impossible. Just as the lock on your front door makes it harder to break into your house. That a lock doesn't make it impossible to break in doesn't make it useless. The answer to your question is "nothing". The browser cannot distinguish between a legitimate self-signed certificate and a MITM attack. That's why using a self-signed certificate brings up the warning for a MITM attack. It's just as when you type your password incorrectly you are denied access to your computer. The computer cannot distinguish between a legitimate user typing a password incorrectly and an intruder trying to get in. Password do not make it impossible for intruders to get in, but that does not make passwords useless.

Re:Self Signed certs + fingerprint

[roman_mir]

The browser cannot distinguish between a legitimate self-signed certificate and a MITM attack

1. Browser can't distinguish between MITM attack with or without a CA signed certificate either.

2. Where did you see me asking a browser to tell me that there is MITM attack in progress?

That's why using a self-signed certificate brings up the warning for a MITM attack.

- but it does NOT do it for plain old HTTP!

Why not? Do you know how often MITM attacks are implemented with just DNS look ups coming from browsers? Probably half of the ISPs out there are intercepting and redirecting your DNS calls. That's a MITM attack and you don't see a browser notifying the user about that little piece of information.

Again and again and again and again and again and again, I am not talking about MITM, I am not talking about providing 'security', I am talking about encryption between 2 points, and whether there is MITM in progress should not be left up to the browser or a CA to decide, but should be delegated to the user, who needs to know what the fingerprint is.

Don't give me a little 'lock' icon for HTTPS, but don't treat self signed certs like viruses. Don't put a lock in front of HTTPS sites with self signed certs, just give an icon for fingerprint, so that it can be looked at immediately without going through any menus.

Which part of: I do not want browsers to deal with security, I just want them to encrypt traffic if HTTPS is used is not clear?

If the SOP is to put a lock icon into the address bar for CA signed certs, that's fine. I don't trust CAs either, so I verify who I am connected to.

But for the self signed certs on HTTPS to be treated as if the computer is under attack and to confuse a normal user instead of silently encrypting the traffic and providing an easy way to verify the fingerprint - this speaks volumes about the corruption and the under the table dealings between the browser developers and CAs.

Re:Self Signed certs + fingerprint

[spitzak]

I think you may be saying the same thing I am. On an SSL connection, a MITM attack can be detected if the SSL certificate *changes*. The only way the MITM attack can be missed is if he manages to interrupt EVERY SINGLE CONNECTION including when your machine first got the certificate.

The current behavior of throwing up a scary warning on the first one just causes people to not use SSL at all for their pages, thus making this MITM detection impossible. Yes it is true that a MITM might be there at the start, but since you get the SAME scary warning whether or not he is there, it is helping absolutely none.

What I would like to see is for self-signed certificates to be silently accepted, with the lock icon removed from the url line. There can also be schemes of proxy trusted agents that can confirm self-signed certificates with (ie that they have not changed and many machines in different locations all see the same one for a site) that I think will produce much higher levels of security than any signing authority.

Re:Self Signed certs + fingerprint

[Anonymous Coward]

Seriously?

Most users DO want the browser to handle security. When your grandma goes to checkout.google.com, how is she supposed to "Check the fingerprint"? Where would she get the fingerprint from? Look it up online? ha. The only realistic option is to have something like CAs. Just like the bartender doesn't want to be responsible for determining your age, so she looks at your government issues ID, not everyone wants to try to manually identify if Amazon.com's servers are real, etc.

On the other hand, warnings of self-signed certs are usually a sign of someone who has no idea what they are doing. (If you are a large organization with reason to issue self-signed certs, then you can always add your own root cert. to the web browser you are using). If the web browsers didn't show any warning message, then someone could make a self-signed cert for amazon.com and use it to rob your grandma a little too easily. In the opposite way, really browsers shouldn't even allow end users to bypass such warnings, because far too many people will click "ok" without actually reading.

At any way, what you personally want from the web browser is not normal.

The reason why there is no warning for HTTP is because there is no expectation of privacy. When you tell people "You are using encryption now", and then the encryption is not actually protecting them, that's worse, since people now believe they are safe when they are being tricked. Obviously the browser should prevent this as much as possible.

Browsing secure vs. buying secure?

[ArundelCastle]

I definitely like it when my bank keeps their cert current. I don't really care so much when I'm buying a silly $16 t-shirt. If that site doesn't have a current cert at checkout and they do have a PayPal or Google option, I'll go that route for the 2 things I don't want in cleartext. (payment and address)

Enigform

[Anonymous Coward]

Everytime an SSL discussion pops up, I mention Enigform and mod_openpgp.
its openpgp for http.
search wikipedia

No

[Anonymous Coward]

No. Next question?

It's Easy!

[jimmerz28]

Can't we just use Angie's List to let us know who reliable sites are? Or Super Pages?

Re:It's Easy!

[bunratty]

SSL is not about determining the reliability of a site. It's about verifying that you're talking to the site you think you're talking to so you don't send your password to an attacker.

Re:It's Easy!

[jimmerz28]

If the sarcasm hadn't come through with Angie's List I thought the Super Pages would be a dead giveaway...

Re:It's Easy!

[bunratty]

But SSL has absolutely nothing to do with the reliability of a site. Even as a joke it doesn't work.

Re:It's Easy!

[jimmerz28]

Verifying that the site you're talking to is the actual one you think you're talking to isn't a test of how reliable/trustworthy a site is? Seems like a good usage of the adjective to me.

Re:It's Easy!

[bunratty]

No, the two things have nothing to do with each other. I can be sure I'm in a sleazy liquor store. That doesn't mean the store is trustworthy or reliable. If I had an item that I had to make sure go to the store clerk, I need to know that I'm in the store. I do not care how reliable or trustworthy it is if I just want to make sure I give the item to the clerk.

If you think the padlock on an HTTPS site means you can trust the site itself, you're very, very mistaken! It only means that when you type your credit card information on the site, only they will be able to see it. It doesn't mean they won't post it in a public location or use it to rack up charges on your account. It means the communications channel is secure. That the communication is secure is reliable and trustworthy. Understand the difference?

Six Degrees

[Anonymous Coward]

Maybe the solution is a distributed web of signing trust?

I mean, *somebody* works at Amazon.com right?

That *somebody* has to have *some* friends right?

I know my friend Eric in real life, he knows his brother Marc in real life, Marc was college roommates with Steve, and Steve got a job at Amazon.com.

Shouldn't these verified in-person connections be enough for me to establish Amazon's identity? Especially if I have multiple verified paths in my social graph to the same entity?

Let me just say it for the hundreth time

[bytesex]

Scrap CA's - start with an empty list. Break up the concepts of verification and encryption.

Re:Let me just say it for the hundreth time

[bunratty]

What good is encrypted communication if you can't verify who you're communicating with? Would you feel comfortable sending me your banking credentials over an encrypted link?

Re:Let me just say it for the hundreth time

[impaledsunset]

An empty start is what you have anyway – you start by downloading a browser over a non-secured link that trusts a given list of CAs.

Re:Let me just say it for the hundreth time

[v(*_*)vvvv]

What's worse is that the encryption part is free, and verification easily could be free too.

The whole industry is built on the false notion that notaries provide encryption, when all they do is make browsers stop complaining. If browsers didn't complain about certificates or show fancy colored address bars, this industry would not exist.

What's even worse is there are enough people that don't even check URLs in the first place, making verification a non-issue!!!!!

Re:Let me just say it for the hundreth time

[bunratty]

I was referring to "Break up the concepts of verification and encryption." Do that and you get encrypted communication with... someone. That isn't secure.

Re:Let me just say it for the hundreth time

[bunratty]

Verification is an issue for those that do check URLs. And verification is already free with certs from StartSSL.

Re:Let me just say it for the hundreth time

[nedlohs]

Breaking apart verification and encryption doesn't mean doing away with verification, it just means having encryption as a stand alone option.

Yes, it opens up man-in-the-middle attacks. But a man in the middle is a lesser than evil than no encryption at all in which every one in the path can snoop. Obviously you would layer authentication as well for things that need it (such as banking) and not bother for things which don't (such as browsing cnn.com).

Re:Let me just say it for the hundreth time

[bunratty]

We already have that option. Use a self-signed cert and you get encryption without verification. The user gets a warning that the recipient isn't verified. With a good browser, the user can accept the certificate upon the first visit to the site and never see the warning again. At least, that's what Firefox does.

Web of trust

[prowley]

A web of trust is only as trustworthy as the least trustworthy member of the web.

Re:Web of trust

[m50d]

You choose how much trust you allocate to each member - though I imagine most users wouldn't care enough to change the defaults.

Re:Web of trust

[Onymous Coward]

A web of trust is only as trustworthy as the least trustworthy member of the web.

That's more like a "chain of trust".

Re:Web of trust

[prowley]

This is impractical for any useful scale.

Re:Web of trust

[prowley]

Certainly shares that characteristic, yes.

Re:Web of trust

[Onymous Coward]

I think maybe I haven't been clear.

As time goes on, you will accumulate keys from other people that you may want to designate as trusted introducers. Everyone else will each choose their own trusted introducers. And everyone will gradually accumulate and distribute with their key a collection of certifying signatures from other people, with the expectation that anyone receiving it will trust at least one or two of the signatures. This will cause the emergence of a decentralized fault-tolerant web of confidence for all public keys.

Web Of Trust, via WP, emphasis mine

If I trust A but not B ... and they both make claims about the identity of C ... it still works. The least trustworthy identity in my web is B, but because it's a web, I'm able instead to trust A. Thus my web is more trustworthy than the "least trustworthy member".

Trusting your connection to the mall

[tepples]

connect enduser device to "the mall" and as long as you trust your VPN connection to the mall, and the VPN connection from the mall to "vendor" (amazon, whatever)

How is that any different from the status quo? Amazon, eBay, Etsy, and the like are malls (trading platforms with multiple vendors), and the VPN connection to the mall isn't much different from a TLS connection to Amazon's checkout server. So how would one trust a VPN connection to a mall? One might use route diversity and key continuity to detect MITMs, as the Perspectives project does. That would help against a MITM between the Internet and the shopper, but it wouldn't detect a MITM that has sat between the Internet and the mall since day one.

RFC 4398

[tepples]

The DNSSEC layer only verifies no one has altered the port 53 packets. [...] SSL layer encrypts the whole data stream.

Then use them together. Have each domain owner run his own CA and use an RFC 4398 resource record to put the certificate for that in DNS. If a TLS connection's certificate chain ends up at an untrusted certificate, the browser would fetch a CERT RR for the domain and treat the result as a domain-validated intermediate CA certificate signed by the DNSSEC root.

Re:RFC 4398

[goofy183]

Man I wish I had mod points. +1

Re:RFC 4398

[Gyorg_Lavode]

Moxie's point is that, even if you use DNSSEC and SSL, you're still trusting your registrar, the TLD, and ICANN implicitly. If you can't trust all those certificate authorities, why would you trust the DNS hierarchy? I think he's got a great point given how the US Gov's been using DNS to block illegal content.

Personally, I favor a blended economy that phases out CAs. Let DNSSEC + certificate distribution exist. This helps cut CAs out and make certificates accessable to the masses. Next, add on the convergence/perspectives process for retrieving certs. If you are lazy, your browser gets the cert directly only. However, the more you manage your notaries, the more secure your connection becomes. And we can get rid of the CAs.

And this MUST happen. As user endpoints become almost exclusively wireless (cellular, wifi, whatever), the ability to be the man in the middle becomes extremely worrysome. Add to that the fact that apps are communicating flexibly over the internet with little user insight and you have a huge storm brewing. The big companies have no problem getting the certs they need, but what if every single blog you visit has a MitM iframe inserted. What if hackers sit, record network traffic from every app, fuzz it, and then MitM injects into the apps? The answer is you NEED SSL on every connection, period. You can only get that if certs can be securely distributed free which means the CA system HAS TO CHANGE.

Session IDs

[tepples]

OpenID and other SSO type things is a better solution for keeping login credentials safe (well known site is the only place you log into it can use crypto keys stored in your browser)

How does OpenID help keep logged-in users' session IDs from getting firesheeped?

Re:Session IDs

[silas_moeckel]

And ssl will stop it how? Depending on how it's setup your not using a username/password pair or even authenticating on the computer your browsing on.

Re:Session IDs

[tepples]

As I understand OpenID, a server acting as a relying party creates a session ID pseudorandomly, associates it with the credential information received from the OpenID provider, and sends the session ID to the client in a cookie. Then the client sends it back on each request. If this cookie isn't protected from eavesdropping with SSL, it can get firesheeped.

Dictators with trusted root CAs

[tepples]

Anybody can create an SSL certificate for any domain given the right access and if you or your computer accepts a certain CA

If you own the secret key of a public root key for a CA that is installed on the victim's PC, then yeah.

I guess guruevi's point is that a lot of sovereign states know such secret keys, and many of these countries aren't the best of friends with industrialized free-speech countries: Turkey, China, B*lg**m (pardon my French), etc. One possible way to mitigate this is not to allow, say, Gobble-Gobble CA in Turkey to sign the certificates of sites aimed at the U.S. market.

Replacement

[Onymous Coward]

Out of 140+ comments here only two mention Convergence. Yours, and a kind of incidental mention earlier. Even I missed it because I focused only on Marlinspike's old blog article.

Focus, people: Convergence

Look it over and see what you think.

replaced?

[Onymous Coward]

If folks involved in Perspectives (Mr. Wendland?) are watching this discussion, could you comment on the arrival of Convergence? It's relationship with your work?

I advise: boycott GoDaddy

[Onymous Coward]

I would rather you do the legwork. I was trying to prompt you.

As of the publishing of Marlinspike's article Bob Parsons was majority shareholder. It's his company. He's since sold most of the company off -- he's now under 50% -- but he's still the biggest shareholder.

Bob Parsons started the company, he owned the company, he owns the biggest chunk of the company now, his ethics continue to be highly influential. The company's history of controversy shows his influence, either directly or by setting a tone for behavior: http://en.wikipedia.org/wiki/Godaddy.com#Controversies Have you heard about Bob Parson's stance on torture?

In short, the quality of GoDaddy is related to the quality of Bob Parsons.

Re:I advise: boycott GoDaddy

[Anonymous Coward]

The article says, GoDaddy is controlled by a guy who hunts Elephants and therefore you shouldn't trust GoDaddy. That is ad hominem and in no way a rational argument regarding the trustworthiness of a DNS registrar. If GoDaddy has given reason to distrust them, then Marlinspike should have pointed to that. He did however point to Elephant hunting.

government IDs?

[reiisi]

You think what the government has done with passports and driver's licenses (and SSNs) so far has been better than the mess made by the Joe Random guys who decided to be the root CAs?

I'm not sure. I'm also not sure the government should do a better job. I'm not sure it's the government's job to tell me my wife is my wife or my children are my children. Or my friend is my friend. Etc. If I have to ask such questions, I think there are fundamental issues that ID simply cannot deal with.

Re:government IDs?

[chill]

ID is for dealing with people you don't know, not friends and family. Not all interaction is in depth enough for you to have to establish personal knowledge.

Online sales are something you really just need to sometimes know Bob is Bob without having to learn his family history.

Re:government IDs?

[Anonymous Coward]

With online shopping, it doesn't really matter that you know that Bobs Web Shop is actually Bobs Web Shop, when you don't know whether or not you can trust Bob.

If you had done business with Bob before, it does help to know that you're still communicating with Bob, but the SSH solution of remembering which certificates you have accepted before solves that problem just fine, without needing to trust anyone.

Broken?

[reiisi]

We aren't broken. We are supposed to be this way.

This conscept of trust is broken. Misapplied, as well.

math blocker

[reiisi]

We are asking the math to do something it can't do.

No semantics in mathematical symbols, no matter how hard we try to impose them from the outside.

"Root of trust" is a wrong idea. Just Plain Wrong.

Different kind of trust.

[reiisi]

If you say our whole society is reliant on inherited trust, either your society is not my society, or the trust of which you speak is not the trust in which root CAs tell everyone whom to trust.

There are two kinds of trust in operation here, and the current implementations fail to distinguish them properly.

Re:Different kind of trust.

[amorsen]

the trust of which you speak is not the trust in which root CAs tell everyone whom to trust.

Correct, that is not the trust I speak of. I trust a policeman because he has a government-issued ID. That is inherited trust. I don't trust him unconditionally, but I do get out of the car when he asks me to. Trust DOES inherit.

Of course, sometimes that trust is abused. Sometimes even by a mass murderer. Nevertheless, society can't function without it, because we can't form deep bonds with everyone before we do transactions with them.

Re:Different kind of trust.

[reiisi]

Actually, I'm not sure the reason you get out of the car is that you trust the policeman. Unless you mean that you trust that the policeman is more likely to cause you problems than not if you don't follow his invitation.

MITM on the server's side of the connection

[tepples]

So Perspectives would stop coffee shop MITMs. But the MITM could still touch responses if the MITM were to insert itself between the server and its only upstream connection to the Internet. Then all notaries would see the same MITM'd certificate. This might happen under a government that censors the part of the Internet that reaches its soil.

Re:MITM on the server's side of the connection

[icebraining]

Yes, sure, it's not magic. You can ask Canonical to send you an Ubuntu CD which comes with the certs ;)

Re:MITM on the server's side of the connection

[tepples]

Perhaps I was unclear. I wasn't talking about MITMs between the user's computer and the server from which Perspectives software was downloaded, MITMing every download of Perspectives. I was talking about a MITM between the HTTPS server and the Internet, such as an HTTPS server in a country whose government puts MITM on all HTTPS connections that leave the country. I don't see how mailing Ubuntu install media would help in that case.

Re:MITM on the server's side of the connection

[icebraining]

Well, I wasn't talking about Perspectives itself, but on any hypothetical system which would replace the current model.

In theory, such system would be implemented by the browsers themselves, which would come with the necessary certs, and the Ubuntu CD comes with such browsers (like Firefox).

Notaries

[ediron2]

Have scanned the comments, am not seeing discussion of Notaries.

If you're not talking notaries, or you're saying 'Moxie didn't describe his alternative', it just means you missed (or were asleep / hung over) at the Defcon panel by Marlinspike & Diffie (and questions from Hoyt Kesterson, a former chair of x.509 standards). Go back and reread the 2nd link, especially the last few paragraphs. Moxie's April blog entry didn't get into Convergence, which is an attempt to flip the model upside down.

Everyone talking about trust and signing parties, congratulations: you pretty much independently arrived at M&D's conclusion about them. Ditto MITM. Ditto DNSSEC (both as a spooky single point of failure and the flaw of shoehorning too much shit into DNS records).

In a nutshell, what drove Moxie nuts was watching as there were NO REPERCUSSIONS when Comodo screwed things up terribly. And since web browsers can't/won't just arbitrarily screw all the corps that buy Comodo crap by dumping Comodo from their CA list, nothing will change.

So, he flipped the model around. Users... well, actually, clients... get to revoke trust relationships. And we would do it via the idea of Notaries. The notary pool might vary based on nationality of users (many people in countryX may not care enough to have a notary that focusses on vouching for countryZ websites), or it might introduce a bit of paranoia: As the panelists mentioned and Naked Security restates, clients might even choose a mutually-distrustful set of Notaries to trust: the US Dept of Homeland Security and a branch of the Peoples Republic of China.

Here's my notes on how Convergence works: an SSL page gets the cert from the website, and requests the cert in parallel from notaries. If there's no match or if one of them flags it, you'd get an alert: distrusted by NotaryX. The distrust mechanism is immediate (a Notary can revoke and know that all future use of that cert will be flagged), and if a notary refuses to revoke a cert after a monumental screwup like Comodo's, the users or client-code developer can comparison-shop and find a notary that recognizes the flip-around in nature of their job (vouching for the validity of 3rd-party certs TO US, not trying to keep getting payments by those who currently buy certs).

FWIW, I wasn't completely convinced by Moxie, though not because of Kesterson's good question (What stops this from becoming another economic race to the bottom, like where SSL certs are bought on price, since the buyers evidently aren't technoliterate enough to grok SSL and flee Comodo like they should). Mine's along the line of Schneier's axiom on how crypto is hard: even an easy and promising alternative needs a bit of hard scrutiny to make sure it isn't just creating a different set of problems.

(whew, talk about tl;dr)

One last thing: when the defcon vids get published, this one's worth watching just for Whitfield Diffie's bit on Defcon presentations needing a glass of scotch whisky vs authenticity of his remarks. Priceless.

IF you "fix" it

[Anonymous Coward]

For gods sake make it simpler. As someone said, why do I need Authorities and all that other cr@p. All I should need is a key FFS. Take truecrypt for example- if I don't want to use an unrememberable string of characters I can use a photo of my kids instead...

Re:IF you "fix" it

[slim]

You seem to be overlooking the exact problem that PKI aims to solve.

Let's say you and I want to communicate securely. I need your public key. How do you get it to me? Sure, it's a public key, so it's safe to transmit it in the clear. But by the time I get it, how do I know it's really your key, and not some snooper's? Sure, there are ways around it -- you could phone me, somehow convince me of your identity, and read out a hash of the key -- but that doesn't scale if I'm communicating with dozens, or thousands of correspondents, and you don't want to call everyone you want to communicate with, to set up a key relationship.

What we need, is some way of asking someone we trust "hey, this claims to be John Smith's public key. Is that true?". Guess what. That's a CA.

The problems are:
  - CAs that basically aren't trustworthy
  - That the top-down hierarchy of trust is too rigid for some people's tastes, for certain applications.

check fingerprints

[MadMaverick9]

the fingerprint of the fake "google.com" cert created by the dhs would have a different fingerprint than the real "google,com" cert .

correct?

if "google.com" would post their fingerprint somewhere on their site, then we, the users, could verify it. and then we would immediately notice a fake man-in-the-middle cert,

correct?

and maybe this process of checking the fingerprint could be semi-automated. and then even self-signed certificates would not be an issue anymore.

Re:check fingerprints

[Anonymous Coward]

http://www.google.pl/support/forum/p/gmail/thread?tid=6c8125bbfb6a2672&hl=en

Re:I advise: boycott GoDaddy

[Anonymous Coward]

The point probably being that elephant hunting is both illegal and unethical.

Then there's websites that lie about SSL

[Anonymous Coward]

e.g. http://www.hondafinancialservices.com/ proudly displays a Verisign logo and touts security while, since a few months ago, redirects https to http.

The unaware are entering their login data in the clear, giving sniffers access to payment account data.

Okay, What about the government?

[bdwoolman]

I get that you were being sardonic, WSG. But... as for a gold-standard CA I would trust a USPS verification. Or even a CA that was USPS certified. Or, perhaps, in the case of a foreign CA, maybe Customs-Service certified.

But wait. There's more. Let 's put this into a broader context. I have long thought that the USPS missed the boat when they did not offer protected email services back in the day. What about a two-cent encrypted email with a usps.gov address? Nowadays it would be possible to have a lifetime USPS email account. Bill Gates has maintained forever that a paid email option would solve a lot of problems. He's not ALWAYS wrong. (FIlter. Read USPS Encrypted Only.) Sweet.

Why pay you ask? The pitch would be that such a USPS communication would garner the same constitutional protection as paper mail -- requiring a court order to open it. Even if in some cases it was a pro-forma FISA warrant. Currently, the government can troll email content because legally such communications are in a grey area -- 'broadcast' as they are across the network and (mostly) in plain text. Sure examination of the content on your PC requires a warrant, but plain text on the wire -- not so much. Your stuff in the cloud? Meh! The security community might not like this USPS idea so much, but the Post Office could sure use some extra revenue. Whatever the details of the scheme the US Postal Service clearly has the gravitas to put order into many dodgy areas of electronic communication. This really is a no-brainer for Congress. They'll see the wisdom of these suggestions instantly and pass the requisite laws.

Oh, wait! Never mind. Forget I said anything.

Re:Okay, What about the government?

[WrongSizeGlass]

That makes a lot of sense. I certainly would be willing to pay a few pennies per piece to send email to my clients (or prospects) or other important recipients. Two of my clients have had me look into providers for this type of secure service (primarily for secure attachments but also secure correspondence).

Regular exchanges with my family or other "regulars" wouldn't require this type of service so the cost would be minimal for me and negligible for any of my clients who need this type of service.

web of trust better than heirachy of trust

[sg_oneill]

Whats needed is a web of trust system that lets users define who they trust and who they don't. If I'm doing financial transactions, I'd probably trust *visa* more than some crappy SSL reseller to certify the SSL. If I'm looking at a government page, I'd trust the government. But if I'm looking an anti-government stuff I'd love to be able to say "If the govt is in the web of trust here, let me know, because I dont like that".

Its strange to me that if I set up a store with a credit card I get have to get an SSL from verison, despite the fact I *actually* have to convince VISA I'm safe. What this means is if I'm dodgy , even if VISA goes "Man no dude, your business is a ponzi", my customer visible certification is from verison who has no such protections. Why cant I send my business plan to my bank, the bank then signs a certificate using creds it got from visa which then I can in turn sign for MY subdomains so the web of trust is clear: Shaynes budget dongles is trusted shaynecorp which is trusted by widget-bank which is trusted by VISA, which is trusted by , uh, maybe the WTO (or something) which in turn is trusted by (etc). If I dont want to deal with VISA anymore, I revoke my trust of VISA and any VISA enabled site becomes untrusted so I instead look for ones with Mastercard trustedness.

Political groups could create their own trust chains (and you can inspect them and go "Hey hang on, I dont trust republicans, fuck that , revoke"). Company chains could create their own. But they are all related by a web of trust rather than a heirachy, and from there peoples intuitions about who to trust rather than "I hope verisign isnt issuing garbage SSLs again".

It would kill dead the stupid oligopoly over SSL whilst providing more robust tools for determining who the hell your actually talking to in a secure transaction.

Why did CAs ever begin to exist?

[Anonymous Coward]

The problem is not how CAs act or how many of them there are. The problem is CAs in general, and I cannot for the life of me figure out why anyone ever thought they were a good idea. When I sign up a new set of credentials, they should come with a self-signed certificate *from the place I am getting those credentials* (ie. visa.com).

Any time anyone anywhere wants to verify my identity with visa.com, they can redirect me to visa.com (where I can verify the authenticity via the certificate they issued me) to enter my credentials. On the back end, the requesting site and visa also have a chain of trust involving those two.

- I can trust the authenticity of visa.com, and since they issued my credentials I have no issue with providing them.
- The site can trust the authenticity of visa.com, who they've chosen to do business with.

Bottom line, anywhere that I have an identity I should have a self-signed certificate from that place that comes at the time of my credentials. I will use that forever more to verify I am talking to the right people. Anyone that wants access to some part of my identity with them can make a separate chain of trust with them.

Can anyone tell me why someone once thought it was a good idea to have Verisign tell me whether or not I was dealing with visa? That just adds one more possible weak link to the chain. I've had people come back with such stupidity as "but your browser could intercept the certificate and oh noes!"; as if the browser couldn't already intercept your login details or just not tell you that the certificate you're trusting is invalid.

No SNI in IE on XP

[tepples]

you NEED SSL on every connection, period.

For that to happen, not only do CAs need to die, but either IPv6 has to become widespread or Windows XP and Android 2.x have to die. The web browsers included with those operating systems only support one certificate per IP address/port pair.

Adobe Acrobat

[bdwoolman]

For quick and dirty encryption with my attorney and accountant Acrobat suffices. (IMHO the protection is marginally better that MS Word doc password protection.) I can distill a password protected PDF and attach it. Sure it is breakable, but it shows due diligence on my part. Hacking the encryption to read the content is itself a crime. And makes it a harder target. I give the password to the recipient over the phone. And I make it a good one. I would prefer to use GnuPG, but that requires a learning curve for the recipients.