Beta
×

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

Thank you!

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

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

Can We Fix SSL Certification?

Unknown Lamer posted about 3 years ago | from the security-through-insecurity dept.

Security 249

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

cancel ×

249 comments

Sorry! There are no comments related to the filter you selected.

No (1)

0123456 (636235) | about 3 years ago | (#37109726)

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

Re:No (2)

WrongSizeGlass (838941) | about 3 years ago | (#37110298)

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 (1)

ravenspear (756059) | about 3 years ago | (#37110328)

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

Re:No (0)

Anonymous Coward | about 3 years ago | (#37110386)

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

Well, we've bought into it so far.

Re:No (1)

TheSpoom (715771) | about 3 years ago | (#37110420)

Mod parent up. AES / SHA, anyone?

Re:No (2)

elsurexiste (1758620) | about 3 years ago | (#37110466)

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 (1)

chill (34294) | about 3 years ago | (#37110658)

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 (0)

Anonymous Coward | about 3 years ago | (#37111342)

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 (1)

chill (34294) | about 3 years ago | (#37111542)

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 (1)

toastar (573882) | about 3 years ago | (#37111430)

<quote><p>Actually, that is a good idea.</p><p>The articles aren't really discussing absolute trust, they are talking about only one aspect of SSL -- identification.</p><p>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.</p><p>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.</p><p>We trust the governments with this function now. I don't see what the big issue is in trusting them with the digital version.</p></quote>

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

Re:No (1)

chill (34294) | about 3 years ago | (#37111596)

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 (1)

Archangel Michael (180766) | about 3 years ago | (#37110796)

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 (1)

amorsen (7485) | about 3 years ago | (#37111068)

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 (0)

Anonymous Coward | about 3 years ago | (#37111306)

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 (1)

vlm (69642) | about 3 years ago | (#37110652)

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 (1)

arth1 (260657) | about 3 years ago | (#37110900)

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 (1)

vlm (69642) | about 3 years ago | (#37111064)

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 (1)

arth1 (260657) | about 3 years ago | (#37111524)

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 (1)

amorsen (7485) | about 3 years ago | (#37111096)

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 (1)

arth1 (260657) | about 3 years ago | (#37111334)

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

amorsen (7485) | about 3 years ago | (#37111512)

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 (1)

SmurfButcher Bob (313810) | about 3 years ago | (#37111492)

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.

To quote Bob the Builder (0)

Anonymous Coward | about 3 years ago | (#37110344)

"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 4chan (0)

Anonymous Coward | about 3 years ago | (#37110460)

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

just allow anything. (0)

Anonymous Coward | about 3 years ago | (#37110396)

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

Chris Mattern (191822) | about 3 years ago | (#37110444)

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

Anonymous Coward | about 3 years ago | (#37110554)

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

Re:just allow anything. (1)

jandrese (485) | about 3 years ago | (#37110776)

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

Bzzzt (1)

vlm (69642) | about 3 years ago | (#37110410)

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 (1)

amorsen (7485) | about 3 years ago | (#37111130)

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 (1)

vlm (69642) | about 3 years ago | (#37111294)

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 (1)

amorsen (7485) | about 3 years ago | (#37111528)

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 (1)

he-sk (103163) | about 3 years ago | (#37111672)

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 (1)

Sloppy (14984) | about 3 years ago | (#37111650)

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

Possibly... (1)

dkf (304284) | about 3 years ago | (#37110424)

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.

Make CA's more liable (2)

Animats (122034) | about 3 years ago | (#37110636)

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 (1)

Stellian (673475) | about 3 years ago | (#37111538)

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:Possibly... (1)

Medievalist (16032) | about 3 years ago | (#37110690)

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.

Won't happen. (1)

Anonymous Coward | about 3 years ago | (#37110452)

Not as long as there are Millions to be made.

Distribute Certificates via DNS (using DNSSEC)? (4, Insightful)

SmilingBoy (686281) | about 3 years ago | (#37110472)

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)? (4, Insightful)

vlm (69642) | about 3 years ago | (#37110530)

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)? (2)

CAPSLOCK2000 (27149) | about 3 years ago | (#37110650)

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)? (1)

guruevi (827432) | about 3 years ago | (#37110764)

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)? (2)

vlm (69642) | about 3 years ago | (#37110856)

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)? (1)

arth1 (260657) | about 3 years ago | (#37111116)

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)? (1)

vlm (69642) | about 3 years ago | (#37111346)

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)? (1)

vlm (69642) | about 3 years ago | (#37110766)

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)? (1)

Sancho (17056) | about 3 years ago | (#37111200)

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)? (0)

Anonymous Coward | about 3 years ago | (#37111436)

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)? (1)

silas_moeckel (234313) | about 3 years ago | (#37111000)

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)? (0)

Anonymous Coward | about 3 years ago | (#37110546)

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)? (0)

Anonymous Coward | about 3 years ago | (#37110612)

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)? (0)

Anonymous Coward | about 3 years ago | (#37110714)

DANE [ietf.org]

Re:Distribute Certificates via DNS (using DNSSEC)? (0)

Anonymous Coward | about 3 years ago | (#37110844)

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

AceJohnny (253840) | about 3 years ago | (#37110910)

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

Re:Distribute Certificates via DNS (using DNSSEC)? (0)

Anonymous Coward | about 3 years ago | (#37111268)

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)? (0)

Anonymous Coward | about 3 years ago | (#37111156)

djb => http://dnscurve.org/

Why the fuck should i need an authority ? (1, Insightful)

unity100 (970058) | about 3 years ago | (#37110478)

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 ? (0)

Anonymous Coward | about 3 years ago | (#37110528)

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 ? (1)

lucidlyTwisted (2371896) | about 3 years ago | (#37110792)

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

Re:Why the fuck should i need an authority ? (0)

Anonymous Coward | about 3 years ago | (#37110538)

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 ? (1)

blueg3 (192743) | about 3 years ago | (#37110596)

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 ? (2)

vlm (69642) | about 3 years ago | (#37110570)

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

Re:Why the fuck should i need an authority ? (1)

isorox (205688) | about 3 years ago | (#37110804)

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 ? (1)

vlm (69642) | about 3 years ago | (#37111010)

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 ? (0)

Anonymous Coward | about 3 years ago | (#37111452)

[[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 ? (1)

nahdude812 (88157) | about 3 years ago | (#37111702)

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 ? (1)

guruevi (827432) | about 3 years ago | (#37110892)

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 ? (1)

icebraining (1313345) | about 3 years ago | (#37111282)

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 ? (1)

bunratty (545641) | about 3 years ago | (#37111300)

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 ? (2)

vlm (69642) | about 3 years ago | (#37111426)

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 ? (2)

asdf7890 (1518587) | about 3 years ago | (#37110708)

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 ? (1)

bunratty (545641) | about 3 years ago | (#37110720)

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 [wikipedia.org] .

Re:Why the fuck should i need an authority ? (1)

bigpat (158134) | about 3 years ago | (#37111510)

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.

If not SSL, then what? (0)

Anonymous Coward | about 3 years ago | (#37110500)

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? (1)

fuzzyfuzzyfungus (1223518) | about 3 years ago | (#37110710)

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.

Two problems here (1)

PPH (736903) | about 3 years ago | (#37110686)

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 (1)

sunderland56 (621843) | about 3 years ago | (#37110840)

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 (1)

SiriusStarr (1196697) | about 3 years ago | (#37111220)

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 (1)

icebraining (1313345) | about 3 years ago | (#37111332)

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 (1)

ags1 (1883204) | about 3 years ago | (#37111374)

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 (1)

vlm (69642) | about 3 years ago | (#37111446)

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.

MITM when accessing the notaries? (0)

Anonymous Coward | about 3 years ago | (#37110768)

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? (1)

amorsen (7485) | about 3 years ago | (#37111194)

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"?? (2)

bigpat (158134) | about 3 years ago | (#37110820)

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"?? (1)

m50d (797211) | about 3 years ago | (#37111360)

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"?? (0)

Anonymous Coward | about 3 years ago | (#37111696)

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

No (2)

sl4shd0rk (755837) | about 3 years ago | (#37110836)

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

drolli (522659) | about 3 years ago | (#37110880)

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

amorsen (7485) | about 3 years ago | (#37111242)

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.

Trustability rating ? (0)

Anonymous Coward | about 3 years ago | (#37110984)

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

Self Signed certs + fingerprint (2)

roman_mir (125474) | about 3 years ago | (#37111036)

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 (1)

Spad (470073) | about 3 years ago | (#37111290)

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 (2)

roman_mir (125474) | about 3 years ago | (#37111432)

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!

Browsing secure vs. buying secure? (1)

ArundelCastle (1581543) | about 3 years ago | (#37111056)

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 (1)

Anonymous Coward | about 3 years ago | (#37111084)

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

No (0)

Anonymous Coward | about 3 years ago | (#37111100)

No. Next question?

It's Easy! (1)

jimmerz28 (1928616) | about 3 years ago | (#37111158)

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

Six Degrees (0)

Anonymous Coward | about 3 years ago | (#37111276)

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 (1)

bytesex (112972) | about 3 years ago | (#37111566)

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

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

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

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

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

<ecode>    while(1) { do_something(); } </ecode>