What the fuck are you talking about? In the real world, shell scripts are used all the time. Despite their failings relative to more complex languages like Python and Perl, shell scripts are very easy to generate from repeated manual invocations of command lines.
In other words, to scratch an itch with a Python script requires writing your command over again. With a shell script, you can build on the commands you've already typed. Shell scripting is the original RAD, and remains very useful today.
Why make the free CA ones orange but not do anything about self-signed?
Because self-signed certificates are bad for a number of reasons, including non-revokability, trivial spoofing, and expiration turnover problems. Free CAs accomplish the same goal without any of the problems. The only advantage self-signed certificates have is a base emotional appeal to decentralization.
paying for a certificate doesn't guarantee the checks are any more fool-proof
At the very least, there is a paper trail of payment. That by itself is a good thing.
Having degrees of security would be good in theory
We already have degrees of security. A three-level system is not too complex for almost everyone to understand, and the padlock icon check will be more than good enough in the vast majority of circumstances. Adding a rule stating "the color has to be yellow or green for it to be safe for credit card information" might help too.
I don't think the dancing bunny problem is quite so severe when users have to enter their credit card numbers or bank account information. The media has done a good job of whipping up a frenzy about identity theft.
Most users do not know what a certificate is for....They have been trained to know that if a secure icon is present it's good.
You're right. We can't count on users being any more than idiots. They'll just look for a secure icon. The trick is convincing them to look for the correct security icon, and to check that the address in the browser matches the site in the window.
These techniques are very simple, on par with looking both ways before crossing the street. I think almost everyone can be taught basic due diligence when it comes to security.
Having a CA funded by anyone but the website also doesn't work, since the site needs to get a certificate from the CA before going live.
I don't see why a site requesting a CA needs to be live. Consider FooCA, a for-pay CA that users subscribe to, or that ISPs subscribe to on behalf of their users. (There are other models --- this is just an example). If BarInc wants a certificate from FooCA, BarInc just applies to FooCA as soon as BarInc incorporates and obtains BarInc.com. Why would BarInc.com need to be live at this point?
Hmm, there's a thought. Self-signed certs, with the root cert fingerprint available as a DNS record, using DNSSEC. Then get the real-world identity info from 'whois'.
That's a thought. But first we need DNSSEC, which would make me a happy man in any case.:-)
Or use something based on "can't fool all of the people all of the time" like Perspectives
That solves some problems, but I'd rather have a robust CA system so that nobody has to be in that group of fooled people. Perspectives also adds significant latency to the connection and has other technical problems, but combined with other security measures, I don't see it as being all bad.
I'm going to stick my neck out and say that SSL is a false security....I'm much less worried about packet sniffing, and more about fake sites
SSL works very well for the kind of attacks it was designed to counter. We need other mechanisms to protect against others. Why would you expect one technique to cover all vulnerabilities?
Major browsers already include anti-phishing features that check blacklists. These blacklists will reduce, but not completely eliminate, the fraud caused by phishing schemes. A few people will always fall prey to them, but through education and centrally-managed blacklists, we can hopefully reduce the number far enough that phishing becomes more trouble than it's worth.
The problems you identify with the CA infrastructure are real, but switching to an SSL-style OH-MY-GOD-THE-CERT-CHANGED system introduced vulnerabilities to several different attacks, desensitizes users to security problems, and cannot provide assurance of identity --- only that the site is the same one that you spoke to last time.
Closing your eyes, plugging your ears, and singing "la la la ssh la la la self-signed la la la" won't solve a single thing when someone uses a MITM attack to intercept the first connection to a site.
We can better address the CA problems by making incentives line up in the correct way. Change the system so that the CAs have a financial incentive to not issue fraudulent certificates --- either regulate them, allow regular users to subscribe to a CA verification service, or require that more than one CA sign a particular certificate.
They handing out mod point to everyone these days or what?
No, they must be handling out mod points to people who have a fucking clue how SSL works. SSL is designed specifically to counter your simplistic scenario.
the mitm intercepts (and blocks) client's attempt to start an ssl session with bank, instead the mitm makes the ssl connection with the bank AND the client. Where is your https and padlock icons now?
The MITM won't be able to give the client the proper certificate for the domain name the client thinks he's connecting to. The browser will detect this mismatch and give the user a broken padlock icon and a security warning. Because we've educated the user, he'll know to look for the padlock icon, and that a broken padlock icon means "danger". Attack averted.
No, I'm talking about truncating the domain name in the middle, not the entire URL. Long URLs will still have their path and query-string portions trail off to the right, but the beginning and end of the domain name will always be visible.
No, the solution to to encrypt everything on the Internet. Everything should be SSL across the board.
That'd be nice, but it's not going to happen soon, and for plenty of different reasons. We need to focus on solutions that are feasible now, not pie-in-the-sky ideas that will only be implemented after even more massive damage is done.
That's another good idea, but I think users might not be alarmed by seeing the entire address bar highlighted in that way as long as it still readspaypal.com/foo/bar/qux/blah/blah/blah. Again, it's the difference between making a security indicator subtle and making it almost impossible to miss.
It should just let me through, say it's using a self-signed cert, and warn me again if the cert changes
One problem with this approach is that it's impossible to revoke a self-signed certificate if it's compromised. Another is that users will always see the OH-MY-GOD-THE-CERT-CHANGED warning every time the certificate expires, or when the site moves to a conventional CA-signed certificate.
A better option that still gives you want you want is a special free CA that the browser recognizes and that will give the user a different, low-security-indicated UI indicator. This solution still gives you most of what you want and is much more secure for everyone involved.
Another, perhaps more reliable option would be to change how long URLs are displayed. Right now, if a domain name exceeds the length of the address bar, it's truncated on the right. Consider: www.paypal.com/foo/bar/qux/sessionid/12341/do.myevildomain.com. If this URL is displayed as:
www.paypal.com/foo/bar/qux/sessionid/123
the user will be fooled. What if, instead, the truncated domain name looked like this?
www.paypal.com/foo/bar/...341/do.myevildomain.com
That way, no matter what evil junk is in the domain name, the user will see both its beginning and end and know something strange is going on.
I do not like the whole "EV certification" thing. Not because I dislike the process or what it's designed to do, but because CA's were already supposed to be doing the verification in the first place (apparently, they weren't). Now they want to charge more money to do what they were originally supposed to do.
Like most human behavior, this problem can be explained by economics.
The problem is that the CA system creates the wrong incentives. You, as a CA, want to sell as many certificates as possible. There are almost no repercussions for issuing a fraudulent CA. In theory, browsers are supposed to remove rogue CAs from their CA lists, but in practice that doesn't happen: they're too afraid of "breaking the web" and being sued to actually punish CAs for having lax security.
Comodo, for example, delegates its CA business to fly-by-night subsidiaries who issue certificates with no verification whatsoever. This is the worst situation imaginable from a security perspective, but even after this contemptible practice was exposed, neither Microsoft nor Mozilla Corp. removed the Comodo root certificate. I've personally removed it in all the browsers I use, but most users won't do that.
Comodo's behavior is no surprise, however. For them, it makes sense from an economic point of view. Yelling and screaming will change nothing. The EV program is slightly better in that it's an industry agreement to perform better validation, but it'll inevitably succumb to the same market forces. As EV certificates become more entrenched, it'll become too difficult to punish rogue EV vendors, and we'll be in exactly the same situation we are today with standard SSL certificates.
CAs validating websites and taking payment from them creates the same perverse incentives that led credit rating agencies to contribute to the current economic crisis. You can't count on people's goodwill to make them do the right thing: if you want the right thing to happen, you need to make the right thing the easy or profitable thing.
There are a couple solutions to the incentive problem:
Make users pay CAs to validate websites: this puts the economic incentives in the right place, but users will resent paying for what used to be "free". Personally, though, I'd subscribe to an enhanced validation service.
Change CAs into non-profits: the problem with this approach is that funding would then have to come from the government or some other organization. Can you imagine "PayPal, stop accepting payments for contraceptives or we'll revoke your certificate, you liberal hippies"?
There is nothing you, as a web application developer, can do to mitigate this problem other than educating users and busting the IT department's balls to get them to improve real network security.
(Well, you could use clever Javascript to try to heuristically detect funny business in the page location, but if you're important enough, an attacker will just the detection Javascript when proxying your site.)
And what about servers using vhosts on a single IP?
More people need to use RFC3546 Server Name Indication for SSL name-based virtual hosting. All major browsers already support it; the only barrier is Apache and OpenSSL. mod_gnutls for Apache, however, works perfectly.
Even in the absence of RFC3546 support, there are several workarounds:
Your form has to submit a single, non-virtually-hosted URL to work properly anyway. Just put the page that displays the form in this location as well.
Use a wildcard SSL certificate
Purchase additional SSL certificates
Frankly, if you're legitimate enough to be accepting sensitive information over SSL, you have the resources to use employ of these options.
The solution to this is really to stop using HTTPS for 'secure' access and use something better
Let me guess: you think SMTP is to blame to spam, too.
In both cases, the protocol is not the problem. In fact, both protocols are well-designed and effective. Blaming the protocol is a gross oversimplification of the problem and a cop-out. If you were to do enough work to propose a solution, you'd realize that quickly. Any new protocol that did the same job as HTTP or SMTP would run into the same intrinsic problems these protocols face today. You can't pretend these problems will go away if you shuffle some bytes on the wire around and publish a new RFC.
If you want to solve the problem, you need to change the model these protocols embody. What would be your proposed change, exactly?
Slashdot Mirror
What the fuck are you talking about? In the real world, shell scripts are used all the time. Despite their failings relative to more complex languages like Python and Perl, shell scripts are very easy to generate from repeated manual invocations of command lines.
In other words, to scratch an itch with a Python script requires writing your command over again. With a shell script, you can build on the commands you've already typed. Shell scripting is the original RAD, and remains very useful today.
Because self-signed certificates are bad for a number of reasons, including non-revokability, trivial spoofing, and expiration turnover problems. Free CAs accomplish the same goal without any of the problems. The only advantage self-signed certificates have is a base emotional appeal to decentralization.
At the very least, there is a paper trail of payment. That by itself is a good thing.
We already have degrees of security. A three-level system is not too complex for almost everyone to understand, and the padlock icon check will be more than good enough in the vast majority of circumstances. Adding a rule stating "the color has to be yellow or green for it to be safe for credit card information" might help too.
Good point. What about completely stripping punctuation from IDNs?
Okay, so that will show up as:
https://mybank.com/b...h34.bE/real_path_here
It's clear that something is wrong.
Start->Run firefox -ProfileManager -no-remote
Create a profile called, say, 'bank'.
Then run
Start->Run firefox -Pbank -no-remote
Nifty. Thanks.
I don't think the dancing bunny problem is quite so severe when users have to enter their credit card numbers or bank account information. The media has done a good job of whipping up a frenzy about identity theft.
You misunderstood my point. That's not the warning I'm talking about.
I'm talking about a far more selective warning.
You're right. We can't count on users being any more than idiots. They'll just look for a secure icon. The trick is convincing them to look for the correct security icon, and to check that the address in the browser matches the site in the window.
These techniques are very simple, on par with looking both ways before crossing the street. I think almost everyone can be taught basic due diligence when it comes to security.
I don't see why a site requesting a CA needs to be live. Consider FooCA, a for-pay CA that users subscribe to, or that ISPs subscribe to on behalf of their users. (There are other models --- this is just an example). If BarInc wants a certificate from FooCA, BarInc just applies to FooCA as soon as BarInc incorporates and obtains BarInc.com. Why would BarInc.com need to be live at this point?
That's a thought. But first we need DNSSEC, which would make me a happy man in any case. :-)
That solves some problems, but I'd rather have a robust CA system so that nobody has to be in that group of fooled people. Perspectives also adds significant latency to the connection and has other technical problems, but combined with other security measures, I don't see it as being all bad.
SSL works very well for the kind of attacks it was designed to counter. We need other mechanisms to protect against others. Why would you expect one technique to cover all vulnerabilities?
Major browsers already include anti-phishing features that check blacklists. These blacklists will reduce, but not completely eliminate, the fraud caused by phishing schemes. A few people will always fall prey to them, but through education and centrally-managed blacklists, we can hopefully reduce the number far enough that phishing becomes more trouble than it's worth.
Hopefully, the anti-phishing features of recent browsers will reduce the danger of this attack vector.
The problems you identify with the CA infrastructure are real, but switching to an SSL-style OH-MY-GOD-THE-CERT-CHANGED system introduced vulnerabilities to several different attacks, desensitizes users to security problems, and cannot provide assurance of identity --- only that the site is the same one that you spoke to last time.
Closing your eyes, plugging your ears, and singing "la la la ssh la la la self-signed la la la" won't solve a single thing when someone uses a MITM attack to intercept the first connection to a site.
We can better address the CA problems by making incentives line up in the correct way. Change the system so that the CAs have a financial incentive to not issue fraudulent certificates --- either regulate them, allow regular users to subscribe to a CA verification service, or require that more than one CA sign a particular certificate.
No, they must be handling out mod points to people who have a fucking clue how SSL works. SSL is designed specifically to counter your simplistic scenario.
The MITM won't be able to give the client the proper certificate for the domain name the client thinks he's connecting to. The browser will detect this mismatch and give the user a broken padlock icon and a security warning. Because we've educated the user, he'll know to look for the padlock icon, and that a broken padlock icon means "danger". Attack averted.
No, I'm talking about truncating the domain name in the middle, not the entire URL. Long URLs will still have their path and query-string portions trail off to the right, but the beginning and end of the domain name will always be visible.
That'd be nice, but it's not going to happen soon, and for plenty of different reasons. We need to focus on solutions that are feasible now, not pie-in-the-sky ideas that will only be implemented after even more massive damage is done.
Of course users won't actually read the warning. The point is to annoy users so that webmasters eliminate the behavior causing the annoying warning.
That's another good idea, but I think users might not be alarmed by seeing the entire address bar highlighted in that way as long as it still reads paypal.com/foo/bar/qux/blah/blah/blah. Again, it's the difference between making a security indicator subtle and making it almost impossible to miss.
One problem with this approach is that it's impossible to revoke a self-signed certificate if it's compromised. Another is that users will always see the OH-MY-GOD-THE-CERT-CHANGED warning every time the certificate expires, or when the site moves to a conventional CA-signed certificate.
A better option that still gives you want you want is a special free CA that the browser recognizes and that will give the user a different, low-security-indicated UI indicator. This solution still gives you most of what you want and is much more secure for everyone involved.
Another, perhaps more reliable option would be to change how long URLs are displayed.
Right now, if a domain name exceeds the length of the address bar, it's truncated on the right. Consider:
www.paypal.com/foo/bar/qux/sessionid/12341/do.myevildomain.com. If this URL is displayed as:
www.paypal.com/foo/bar/qux/sessionid/123
the user will be fooled. What if, instead, the truncated domain name looked like this?
www.paypal.com/foo/bar/...341/do.myevildomain.com
That way, no matter what evil junk is in the domain name, the user will see both its beginning and end and know something strange is going on.
Like most human behavior, this problem can be explained by economics.
The problem is that the CA system creates the wrong incentives. You, as a CA, want to sell as many certificates as possible. There are almost no repercussions for issuing a fraudulent CA. In theory, browsers are supposed to remove rogue CAs from their CA lists, but in practice that doesn't happen: they're too afraid of "breaking the web" and being sued to actually punish CAs for having lax security.
Comodo, for example, delegates its CA business to fly-by-night subsidiaries who issue certificates with no verification whatsoever. This is the worst situation imaginable from a security perspective, but even after this contemptible practice was exposed, neither Microsoft nor Mozilla Corp. removed the Comodo root certificate. I've personally removed it in all the browsers I use, but most users won't do that.
Comodo's behavior is no surprise, however. For them, it makes sense from an economic point of view. Yelling and screaming will change nothing. The EV program is slightly better in that it's an industry agreement to perform better validation, but it'll inevitably succumb to the same market forces. As EV certificates become more entrenched, it'll become too difficult to punish rogue EV vendors, and we'll be in exactly the same situation we are today with standard SSL certificates.
CAs validating websites and taking payment from them creates the same perverse incentives that led credit rating agencies to contribute to the current economic crisis. You can't count on people's goodwill to make them do the right thing: if you want the right thing to happen, you need to make the right thing the easy or profitable thing.
There are a couple solutions to the incentive problem:
I wish I could come up with better ideas.
There is nothing you, as a web application developer, can do to mitigate this problem other than educating users and busting the IT department's balls to get them to improve real network security.
(Well, you could use clever Javascript to try to heuristically detect funny business in the page location, but if you're important enough, an attacker will just the detection Javascript when proxying your site.)
IE's warning appeared on all form submissions. I agree that warning was worse than useless.
I'm talking about warning only when the following conditions apply:
The user should not be able to disable the warning; its existence will lead webmasters to change condition 1.
More people need to use RFC3546 Server Name Indication for SSL name-based virtual hosting. All major browsers already support it; the only barrier is Apache and OpenSSL. mod_gnutls for Apache, however, works perfectly.
Even in the absence of RFC3546 support, there are several workarounds:
Frankly, if you're legitimate enough to be accepting sensitive information over SSL, you have the resources to use employ of these options.
Let me guess: you think SMTP is to blame to spam, too.
In both cases, the protocol is not the problem. In fact, both protocols are well-designed and effective. Blaming the protocol is a gross oversimplification of the problem and a cop-out. If you were to do enough work to propose a solution, you'd realize that quickly. Any new protocol that did the same job as HTTP or SMTP would run into the same intrinsic problems these protocols face today. You can't pretend these problems will go away if you shuffle some bytes on the wire around and publish a new RFC.
If you want to solve the problem, you need to change the model these protocols embody. What would be your proposed change, exactly?