Can We Fix SSL Certification? 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?"
No (Score:2)
SSL certification is just plain broken; in another decade it will have collapsed in a heap.
Re: (Score:3)
Re: (Score:2)
Yes, the NSA has given us a 100% guarantee that their most secure encryption method and servers will be used.
Re: (Score:2)
Mod parent up. AES / SHA, anyone?
Re: (Score:3)
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: (Score:2)
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 F
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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
Re: (Score:2)
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: (Score:2)
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: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:3)
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: (Score:2)
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: (Score:2)
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 o
Re:No (Score:4, Insightful)
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: (Score:2)
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 p
Re: (Score:2)
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.
Trusting your connection to the mall (Score:2)
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 t
Bzzzt (Score:2)
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: (Score:2)
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: (Score:2)
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 p
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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.
Re: (Score:2)
No CA...show my id
And guess who issued that id? A trusted third party, namely the government.
Possibly... (Score:2)
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 (Score:3)
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: (Score:2)
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: (Score:2)
> 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
Re: (Score:2)
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?
Re: (Score:2)
You're right, but disconnecting the problem networks was the obvious remedy for spammers and bot
Re: (Score:2)
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 d
Distribute Certificates via DNS (using DNSSEC)? (Score:5, Insightful)
Re:Distribute Certificates via DNS (using DNSSEC)? (Score:5, Insightful)
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: (Score:3)
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
Re: (Score:2)
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
Re: (Score:3)
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).
Re: (Score:2)
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 solu
Re: (Score:2)
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.
RFC 4398 (Score:4, Informative)
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: (Score:2)
Man I wish I had mod points. +1
Re: (Score:3)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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
Session IDs (Score:2)
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:Distribute Certificates via DNS (using DNSSEC)? (Score:4, Informative)
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: (Score:2)
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 [wikipedia.org] 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
Re: (Score:2)
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: (Score:2)
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.
Why the fuck should i need an authority ? (Score:2, Insightful)
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: (Score:3)
Do you have a solution for MITM attacks? No? Well then.
Re: (Score:2)
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: (Score:2)
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
Re: (Score:2)
"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: (Score:2)
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 [perspectives-project.org].
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: (Score:2)
[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: (Score:2)
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 MI
Re: (Score:2)
Does SSL? No? Well then.
If you don't believe me: ... Visa, RSA (lost some of their keys recently), DoD - you're still not protected against any of them.
- 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,
- Given enough re
Re: (Score:2)
That's still orders of magnitude harder than being able to MITM by simply setting up Apache.
Re: (Score:2)
Re: (Score:3)
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.
Dictators with trusted root CAs (Score:2)
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.
Re: (Score:3)
Re: (Score:2)
See above comment about the browser complaining if the SSL certificate changes.
Re: (Score:2)
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: (Score:2)
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 rev
Re: (Score:2)
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 DNS
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
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.
Two problems here (Score:2)
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 an
Re: (Score:2)
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: (Score:2)
You'd still have a local copy of the notaries' certificates, just like today, so the MITMer can't touch their response.
Re: (Score:2)
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.
"proposing a replacement"?? (Score:3)
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?
No (Score:3)
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. (Score:2)
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: (Score:3)
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: (Score:2)
"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: (Score:2)
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.
Self Signed certs + fingerprint (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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: (Score:3)
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.
Browsing secure vs. buying secure? (Score:2)
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)
It's Easy! (Score:2)
Can't we just use Angie's List to let us know who reliable sites are? Or Super Pages?
Re: (Score:2)
Let me just say it for the hundreth time (Score:2)
Scrap CA's - start with an empty list. Break up the concepts of verification and encryption.
Re: (Score:2)
Re: (Score:3)
And how do you know the signature is the signature of the domain's owner?
Re: (Score:2)
Re: (Score:2)
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 v
Re: (Score:2)
Storing and updating the certificates for a small number of notaries is a lot easier than doing it for millions of sites.