Slashdot Mirror
SSL and the Future of Authenticity
An anonymous reader writes "There has been a growing tide of support for replacing SSL's Certificate Authorities with an alternative authentication mechanism. Moxie Marlinspike, the security researcher who has repeatedly published attacks against SSL, has written an in-depth piece about the questions we should be asking as we move forward, and urges strong caution about adopting DNSSEC for this task."
This, Diaspora, and personal interest by friends have gotten me interested in working on The CAKE Protocol again. My goal is a Python reference implementation that can speak over TCP, email, and possibly IM.
Last time I stalled out once I got a job. I also realized that the protocol design was flawed, and the API design for the internals was awkward. Also, I was all alone in a new city. I have friends who are interested now, which makes it easier. And maker spaces with people to talk to. When you have to work on something all by yourself it's hard to stay motivated.
Need a Python, C++, Unix, Linux develop
Texting one time pads is the ONLY SOLUTION.
I just hope that the many people who will post on here, with all their different opinions will actually take the time to read the article first. I know that is asking for a lot on /. but I can hope. Moxie Marlinspike (what a great name by the way) has really done a great piece of work here and it deserves to be read and digested before being critiqued.
Any of the carrier pigeons that fail to present the secret handshake will have their message discarded and be taken in for questioning.
It seems like the real problem is that any good solution to this issue will, by necessity, require the user to make informed decisions about who to trust and who to not trust. Based on the state of non-technical scamming, the success of confidence men throughout history and the fact that most people just want their browser to take them to whatever is linked off their friends' facebook pages, I can't see that this will ever be resolved.I mean, unless we decide to trust some body to make these decisions for people. Unfortunately, that pretty much brings us back to our current problem.
That's the main problem I see with the author's notion of "trust agility:... it requires action from Joe Sixpack users who just want their browser to work in the same way their TV does.
I tried to click the link, but my employer blocks thoughtcrime.org.
Just as soon as we figure out how to get every browser on every platform updated to support the new standard before it goes live.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
Every SSL web site I care about requires me to login. Why not just make mutual password knowledge part of the SSL handshake and be done with it? Then even if a TLA or someone from a convention in vegas decides to take over the world at least the billions of people who have already established trust won't have to worry.
There is still a problem of initial trust when establishing an account but by punting that to the edge people would be better able to make their own decisions. Is SSL good enough? Or would they for example require me to show up in person with ID when setting up an online bank account?
The real issue with the use of DNSSEC is that CAs verify "who" you are...Not "what" domain you have..in practice I'm not sure anyone cares about that. Such a scheme would theoretically be easier to register a typo domain name close enough to a bank to scrape a steady stream of credentials from unsuspecting victims.
Why not switch to self-signed certs + a notary system like Perspectives? It would at least be an improvement on today's situation, since there would be no need for CAs and there would be some MITM prevention built into the system.
"When information is power, privacy is freedom" - Jah-Wren Ryel
Like many things that are too hard to grasp or solve at a technical level, people tend to shift focus to something more discernible. In this case, it is the fact that millions of people who are a part of SSL need to be persuaded to change. This is called "the devil you know verses the devil you don't know" choice. Since most of the unknown devils are of the same paradigm as the known devil, then the status quo will remain. True, there may be a catastrophe that frightens everyone to adopt whatever seems like a safe harbor at the moment. Barring that, it will probably take a new paradigm, perhaps a transparent network that can converge very very fast, making most catastrophic exploits ephemerally limited in scope. True, that would be far from perfect, but then, what is close to perfect?
I don't have a big problem with the way the chain of trust works. I have software on my computer that allows me to manage the certificates that I trust. That way, I can decide for myself. Since I don't actually want to bother to do so, I defer to my operating system vendor's judgment. They provide a package containing a list of trusted certificates, which I then use. I can have as much or as little control as I want. I think this is a good system.
What I do have a problem with is the fact that many applications will use cleartext connections without complaint, but give ominous warnings when using TLS with self-signed certificates. Sure, self-signed certificates don't provide authentication, but neither do clear connections. With TLS, at least I get encryption. This should be a step up in security. At the very least, security is no worse than without TLS.
I am OK with a warning being shown the first time I connect to a service with a non-trusted SSL certificate, but I feel applications should take a page from SSH here: give a warning that isn't too ominous, and offer the chance to save the public key. Then, next time I connect, if the key matches, go right ahead without a warning. And shout if the key does not match. This should provide good security if the first contact is uncompromised. Importantly, it matches the scariness of the warnings with the risk of the situation.
Please correct me if I got my facts wrong.
Certificate Authorities issue "Relying Party Agreements", which specify their obligations to users relying on their certificates. Some of these specify financial penalties payable to end users.Over the years, as with EULAs, these have been made so favorable to the CAs as to make them meaningless. (See, for example, Verisign's relying party agreement. Or, worse, the one from Starfield, GoDaddy's CA.)
Now it's time to push back.
The Mozilla Foundation should issue a tough standard for CA Relying Party Agreements to get a root cert into Mozilla. One that makes CA's financially responsible for false certs they issue, with a minimum liability limit of at least $100,000. The CA must be required to post a bond. A third party consumer-oriented organization like BEUC (in the EU) or Consumer's Union (in the US), not the CA, must decide claims.
The technology behind SSL is fine. The problem is allowing CA's that aren't doing due diligence on their customers to have root certificates in major browsers. Mozilla all by itself has enough power to tighten up standards in this area. All it takes is the will.
Trust, coming from a central authority, that isn't elected, isn't accountable, and doesn't care about anything other than money isn't viable in the modern world, let alone the post-modern one.
I have software on my computer that allows me to manage the certificates that I trust. That way, I can decide for myself. Since I don't actually want to bother to do so, I defer to my operating system vendor's judgment.
What choice do you have other than deferring to your operating system or browser vendor's judgment? I think you are telling yourself something to avoid a feeling of helplessness. I know you can remove Comodo and such when ready they have had a breach but what can really do about the others? Do you have the resources to audit their practices? Once you remove a CA how do establish trust with any sites that use them as their authority? Do you call customer service and get them to read a thumb print to you? How do you get the contact info for CS, from the website you can't authenticate?
Really I don't think the typical user is empowered to chose at all. Even the power user has few options, the ones they do have seriously limit who that can interact with, require the make bad compromises which are every bit as bad as just trusting the vendor and the CAs.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
From the article:
So the "distributedness" of the two cases [CA and DNSSEC] is exactly the same
This is incorrect. The primary problem with the SSL CA hierarchy is that any CA can sign certificates for any domain. This is not possible with DNSSEC: There is exactly one chain of trust for a domain.
people that we have to simultaneously trust: 1. The registrars
Trusting the registry/registrar and everybody else in the domain chain is already a requirement because control of a domain is the only requirement for getting a certificate from an SSL CA. The SSL CA chain therefore does not add any security on top of DNSSEC.
Additionally, many of the players in the domain game are also SSL CAs themselves or can arguably control one of the established SSL CAs. If you don't trust the operator of a CCTLD, there's a very high chance that the reasons for your distrust apply equally to an SSL CA from the same country. And that's just one of many more entities which can betray you in the standard SSL model.
In summary: DNSSEC requires you to trust much fewer entities, all of which you already need to trust anyway.
No Trust Agility
Trust agility in SSL means that users blindly trust every SSL CA. That's the reason why a server operator can choose to go to a different CA. It's also the primary cause for the problems that standard SSL is facing.
The hope that Verisign is going to be kicked out of the browsers root CA storage if they misbehave is beyond naive. This would immediately invalidate so many certificates that the whole point of SSL would be lost. It is much more likely that Verisign loses the TLDs if they misbehave.
A real system to take care of this issue is possible.
There's a number of problems here, and each one needs to be addressed, but luckily none of them are really all that contradictory. I'll detail a practical system:
Problem 1: A random user needs to be able to connect into the verification system easily.
Solution: Handle this in the same way DNS is handled. When setting up your connection settings (IP address, DNS, etc), include a new setting such as 'SSL Verification Address Book' (henceforth referred to as SVAB). Since most people won't know this as they wouldn't know their DNS server, extend DHCP (the system that gives you your IP and DNS) to also give you a SVAB. The SVAB could be hosted by anyone, but would likely be hosted by your ISP.
Problem 2: A malicious user who is running the SVAB can change any details he wants, and send you his own crafted entries.
Solution: Instead of the SVAB returning the actual tokens, it will only provide the client with a list of 'SSL Verification Servers' (henceforth referred to as SVS). Each SVAB would be responsible for it's own list of SVS. When the client needs to verify a server, it will send a request for that site to all of the SVS in the list.
Problem 3: A malicious user who is running an SVS can change any details he wants, and send you his own crafted entries.
Solution: Since the client has a whole list of SVS, and will receive a response from each one, it will be very easy for the client to detect that an entry has been tampered with. To determine the correct entry, the client would simply go with the majority correct information, and display a warning. If the majority is less than some percentage (75%?), an error could be displayed instead of the warning.
Problem 4: A malicious SVAB could send you a list of SVS servers to which they have altered the entry across all of the SVS servers.
Almost Solution: If a policy is implemented in the client where the servers must come from some minimum number of top level domains, or class B internet routable IP addresses, then the task of setting up the malicious SVS servers could be made extremely difficult. In addition, your SVAB would nearly always be hosted by your ISP - and if you do not trust your ISP, you could switch to a new one. MITM attacks between you and your ISP could be possible as well, but the risk could hopefully be minimized - possibly by your ISP or trusted host for your SVAB providing you with a secure key.
Problem 5: Registering your site with the many SVS servers.
Solution: There's a number of possibilities here: a first come first serve basis whereby you would register your site with one node, and that node would propagate your certificate to other nodes as long as the entry does not already exist. Alternatively, the internet site itself could host it's key (http://internetsite/svskey) and each SVS would be in charge of retrieving the key itself, and caching it. If the key on the internet site changed, a second key might be provided in the previous key to validate the new key. At any rate, this problem should not be too difficult and I believe the internet site hosting it's own key would be by far the best solution as it would make it very easy to set up for the internet site.
So to summarize, you would have a SVAB entry in your internet settings which could be entered manually or automatically via DHCP. This SVAB would provide a list of diverse SVS, which would all be queried by the client. The majority response from the SVS servers would be considered the correct one. Registering your own internet site would be easily done by uploading a special key file.
I believe this takes care of the main fear of TFA, which is that you have to trust someone permanently. In this case, you would only have to truly trust your chosen SVAB to create a very good list of SVS servers. This system would also have the advantage of being particularly easy to implement, as well.
Any security scheme verifying a domain which is not part of the domain name system itself really doesn't make any sense, and is already flawed. Once the domain is verified, it itself can establish a connection based on key exchange and public key cryptography. Our domain system is really what needs an overhaul.
But half TFA's point is that it should at least be *possible* for non-lazy users to decide who to trust. With the current system it's simply not feasible for a user to decide that because Comodo got hacked or because Verisign is co-opted by the Feds you'll stop trusting their CAs entirely, because too many sites you need will stop working.
With a better mechanism in place, those of us who choose to can protect ourselves and create tools to help protect the oblivious masses.
I'm not sure Mozilla all by itself has anywhere near that level of power, but I absolutely stand behind the concept--right now, the only thing the CAs have to lose is their reputation, as if that matters at all. Hey, remember that time you stood around with your friends talking about how Verisign will just give a certificate out to any Joe Schmoe?
The only thing a corporation cares about is money, so if you want me to trust you, put your money on the line. I trust that you'll do everything necessary to protect that.
<xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
If the system is designed such that anyone can choose who they are going to trust, then people who can't make that decision on their own can still rely on others, such as the browser vendors, to make good default decisions for them. As it is now, it is unfeasible for either individuals or browser vendors to stop trusting large CAs due to the disruption it would cause.
This is the best response by far. There is a lot of precedent; for example, a bond is required to transmit money in most US states. Keep pushing this idea.
I sure wish people would stop saying "SSL" when what they mean is "https".
SSL is fine. Other protocols based on SSL (notably, SSH) are fine.
The problem is https was designed badly and uses SSL in a grossly insecure manner and is therefore fundamentally broken.
If the protocol were designed securely, the browser would check that the server cert presented either is the *same* cert that was presented last time the site was visited or at least is signed by the *same* authority cert as signed the previous one. That's a minimum, and it's overwhelmingly more important than the specific identity of the company got paid to sign the thing or whether said certificate authority is on The List. I mean, sure, check that too I suppose, but it is *vitally* important to check that the cert hasn't been issued by a new or different authority since the last time the user visited the site. (Exceptions could be made to that, I suppose, if the previous cert is expired.)
(Yes, yes, a mechanism is needed to allow first-time visitors to a site to verify the identity of the site. This is less important than the current problems, because it's difficult for an attacker to predict first-time visits. At worst you use something very similar to the current mechanism the first time the user visits any given site, at which point the current rash of problems is limited to first-time visits, which are significantly less frequent and MUCH more difficult for the attacker to predict than repeat visits. It might be possible to do better than that.)
Cut that out, or I will ship you to Norilsk in a box.
For example - if I get a (GPG Encrypted) Email from a RedHat employee, how do I know it's real? Simple. RedHat employees put their GPG Fingerprints on their physical-old-school business cards.
If businesses took this approach too, it would work.
For example, why doesn't my bank print their SSL fingerprint (assuming they have those - not really sure) on my credit card, letterhead, and other "official" materials?
Taking this kind of approach literally takes the CA out of the equation. I trust the certificate because I know it's valid - not because someone else says it is.
P.S. With a name like Moxie Marlinspike - it seems like he should have a handlebar mustache.
"The Monkeysphere project's goal is to extend OpenPGP's web of trust to new areas of the Internet to help us securely identify servers we connect to, as well as each other while we work online. The suite of Monkeysphere utilities provides a framework to transparently leverage the web of trust for authentication of TLS/SSL communications through the normal use of tools you are familiar with, such as your web browser0 or secure shell." See: http://web.monkeysphere.info/
One last flaw is that I'm not positive a 256-bit namespace is quite large enough to handle all names that will ever be generated given that the birthday paradox effectively halves this to 128-bits
GUIDs are 128 bits. Have GUID collisions ever been a problem?
Because of the reputation ghd hair straighteners have created for themselves in the UK, there is always anticipation each time something new comes out their doors. MY friend bought the Pink hair straighteners which were an exclusive deal in support of Breakthrough Breast Cancer where ghd hair straighteners would donate a percentage of the sale to the charity.
deskpane.build.236 hashstamp below
This is somewhat off-topic. Do you know of any cheap hashstamp-servers ? By hashstamp-server I mean a place where you can make a datestamped, no-edit, no-delete entry containing say the hash of one of your builds. Not having found one of those, slashdot could make money, by offering the datestamped, no-edit, no-delete feature of discussion-comments FOR JOURNAL ENTRIES. A lite discussion in my Journal for slashdot user xpane, more discussion in the Journal for slashdot user hashstamp.
So anyway for today here is the hashstamp of a release-candidate build for my big idea. Thanks for tolerating this somewhat off-topic post, is there another way I could get the no-edit, no-delete feature without needlessly bothering anyone, perhaps even paying 10-cents for a hashstamp, I WOULD !?
file C:\zzzz\zzzzWcDemo\deskPane_win32_x64_2011_APR_11_00236.zip nbytes 0x4F543D 5198909 CRC32 f66b9662 MD5 3b0e7a6e545f7e7a8a34f6bfd152940a SHA-1 6806f4b125e950685a09314c2e56b361847150a5 SHA-256 95e04cb9a0d1bb953c9c6e68a642a76add61ebc51914a4cbbb95ecff1e08d15f
The messages are warning you that a supposedly trustworthy server might not be what it claims to be. Unencrypted connections are by their nature untrustworthy so unless you want a warning whenever one is opened (hint: that would be about 20 if you open Google's search results in Chrome) there seems little point in reminding you of that fact.
The real problem is not about you, it is about the organisations that rely on SSL like banks. If users get scary security warnings they won't want to use online banking. If criminals can get hold of valid certificates for their own phishing web sites they will lose a lot of money*. Users can't be trusted to look after their own security and a significant number of them don't get the OS updates that would be required by any new system. That is why banks want you to install their own crapware or use a token - they don't really trust your PC.
What we need are fewer registrars and more oversight. Unfortunately that is next to impossible to do because each country wants its own trusted company to issue certs (e.g. China wouldn't want to rely on US certs and vice versa) and the cost has to be kept low to make it viable for small sites.
* UK banking law says they are liable, don't know about US.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
I feel applications should take a page from SSH here: give a warning that isn't too ominous, and offer the chance to save the public key.
Which doesn't help if there is a man in the middle from day one. This has happened in the wild (https://bugzilla.mozilla.org/show_bug.cgi?id=460374).
Internet communications are usually unencrypted, which allows anyone on a hold in the proceed between users' computers and your website, such as online credit card payments, or other important data and information, users’ and the servers are encrypted for safety. Secure Socket Layer known as SSL stands for safety and used widely for securing websites and data transacted being online. When security matters for you and server, organizations usually rely on use of "SSL Certificates" to acknowledge or process the private information from your website and server.
ClickSSL is authorized reseller to buy or renew SSL Certificate from Verisign, Thawte, GeoTrust, and RapidSSL. ClickSSL.com offers EV SSL, Code Signing Certificate, UCC Certificate, Wildcard SSL & more SSL Certificates at market Cheapest price.