Topic: Website Developers, Stop Scaring Away Your Potential Customers (SSL!) (Read 3286 times)

In some ways, plain text is better than a false sense of security, obviously in a pragmatic way it is not. But, why use half measures when the business case for rudimentary security is so easy? You've already done 90% of the work implementing SSL. You can get an entry level signed cert basically for free. One case of fraud due to MITM is going to cost more than a signed cert. You can always upgrade your cert level if there's a business case for it. It's a case of penny-wise, pound foolish. Don't cheap out when you are dealing with money that belongs to someone else. Certs should only be the first step.

@nefai i know you're being sarcastic, but that warning is coming from twitter. I wasn't getting that warning until I enabled that script

@alfred we know, this thread is not directed at glbse in any way any more, at least I hope it's not, they've taken a step. too bad the www subdomain throws a hissy fit, though Nefario could always just create a re-direct.

Oh noes there's a big X and a line through the https!  This must be a dangerous website!

Try...

https://glbse.com

now...

But plaintext http, which is the norm now, is better?

Man in the middle attacks don't have to be expensive or require lots of resources.  All it takes is an opportunity to modify your HOSTS file and put in fake IP addresses for all the banks, hoping you might visit one.  This happens and has been happening for years.  Also, think of all the opportunities to sniff clear text traffic... simply run a Tor exit node, or a VPN service, or a local ISP.  If self-signed certs were the norm and no PKI infrastructure were in place, no matter how poor, MITM and similar attacks would be widespread.

The suggestion that people should just accept self signed certs and to pay no attention to the warning because you know better is, to me, on the same level as suggesting people should accommodate someone with terrible body odor the same as anyone else, and ignore the smell because it is merely unpleasant rather than toxic.

I don't disagree with most of what you or nafai said. If SSL was JUST line encryption, I would accept encryption is better than no encryption. However, it is not, tying it to identity verification is unavoidable. As someone that tries to pay attention to the contents of self-signed certs I feel helpless verifying the identity behind it. I know self signing is "good enough" more than 99% of the time, but with these thing you need to be on top or you will run inevitably run into that less than 1% scenario at a really inconvenient time. I doubt many service providers would eat the cost in the rare case where one of their customers mistakenly accepts a spoofed self-signed cert and are taken advantage of.

I think it's disingenuous to say that signed SSL identity verification is worthless while also saying that the encryption provided by self-signed certs is good enough for production use. Show me one white paper that recommends choosing a self-signed cert over signed cert in a production environment as a best practice and I'll eat my hat. Yes someone could hack a cert authority and issue a valid cert for something spoofing your server. The point is they don't need to hack anything to impersonate a self-signed cert.

Anyway, glad to hear you started using a signed cert Nefario.

Just to chime in on this, everything EVERYTHING nafai has said about ssl is 100% correct.

Self signed certs are no less secure than signed. Signed certs only provide (a horribly low minimum) level of VERIFICATION that the person says who they are, nothing more (more expensive certs have higher standards).

Having an ssl auth cert allows the cert authority to issue other certs for your domain (to for example, governments) which would allow them (whoever they are) to MITM you. It also happens when hackers break into cert authorities systems and steal the private keys for the cert auth (this happened to Komodo).

I don't know if nafai is in the security business but I vouch for his understanding of ssl (and by extension other forms of encryption), pm me and tell me more about yourself.

As for everyone else, I've gotten ahold of a "proper" signed cert so it nolonger throw up warnings, you can relax now.

Nefario

First off, can we agree that there is no such thing as 100% security?  Even with the best SSL certificate available, you're still vulnerable to an employee at paypal hijacking your session or account, or the possibility that someone got a keylogger installed on your computer through a 0day exploit in some browser plugin or your OS itself, or whatever.

Secondly, which is more common, casual packet sniffing or an elaborate MITM setup?  I'm not saying you shouldn't try to defend against both. I'm not saying that at all.  What I am saying is that, if for example you have 1000 domains you'd like to provide basic protection to, and absolutely cannot afford a certificate for all those domains, you have to weigh estimated risk.  I'd rather have 1000 domains protected against 80% of casual attackers than protected against 0% of them because the 100% solution is expensive and the 80% solution scares your customers away.

Yes, a self-signed SSL cert still leaves you vulnerable to some attacks, but packet sniffing happens all the time. It's like if deadbolts cost $200 a year to buy them from the one company who sells them, and you're saying "don't bother using a combination lock on your home, cuz it's still vulnerable to brute forcing the passcode."  Well yes it is, but a combination lock is better than nothing, right?  If deadbolts are frikkin expensive and you can only buy them from "the man", why not use a homebrewed solution so-to-speak?  Because it's not a "perfect solution"?  Well neither is deadbolts and neither is "real" SSL certificates.  There is no 100% security on a computer system unless you put it in a safe at the bottom of the ocean.  You're always vulnerable to social engineering, physical access to your systems, employee theft/fraud, etc etc...

Now imagine if, using a combination lock for your home (because deadbolts are expensive and only sold by 1 or 2 companies), the door manufacturers themselves built in an audio warning whenever someone approached your front door "WARNING THIS DOOR IS ONLY PROTECTED BY A COMBINATION LOCK, IT DOES NOT HAVE A VALID DEADBOLT.  ENTER AT YOUR OWN RISK"  Would that be a good thing or a bad thing?  Shouldn't the door at the very least announce something like, "This security system isn't the best, but it's better than the neighbor's who doesn't have a lock of any kind!"

No, MITM is not THAT elaborate to setup. But you've still got to admit, the number of people capable of setting it up and pulling it off is much, much lower than the number of script kiddies who can put their network card in broadcast mode and read your unencrypted traffic (if they're on one of the hops along the way to your destination site, which would also be required for a MITM)....  It's like saying, sending a secret message to the Russians by courier is so much better than sending it in the regular mail in some kind of code, therefore anyone who sends in the mail by code is stupid for not using a courier, nevermind the fact that hiring a courier to go to Russia is pretty damned expensive.  Not a problem if you have 1 secret message to send, but if you need to communicate with the Russians everyday for normal daily business, and you can't afford to hire multiple couriers every single day....    so since you can't do it the BEST way, ah who cares why bother to do it in code at all, let's just send our messages plaintext and hope nobody intercepts the envelope.  Logical?  I think not.

I repeat, you cannot be 100% secure against all attacks.  Solution 1 is 99% secure and expensive.  Solution 2 is 80% secure and free.  But you have to pay for each solution (license it) on a per-domain basis.  Oh yeah, and solution 1's cost is not a fixed rate, but rather an annual fee.  So is it silly for people to want the protection afforded by the free solution even though it doesn't protect against everything the expensive solution does?  Is it silly for people to complain when the infrastructure tells your customers that you're a bad bad sysadmin for using the "less secure" solution even though it's better than no security at all (plaintext)?

I am surprised that in the midst of all this talking about SSL, that not once has EV (Extended Validation) SSL been mentioned or discussed.  I will give a BTC to anyone who can refer me to any credible example that a government or anybody else received an illegitimate EV SSL certificate for the purpose of surveillance or any other purpose.

EV is technically exactly the same as SSL, it's just far fewer parties can issue them, and it's based on a different chain of trust that has a policy of a much stricter set of controls in terms of identifying owners of certificates.  Sure you can get a $2 SSL cert, but to get an EV SSL, you must pay much more, plus be far more rigorously screened as to your identity.  In return, browsers show a green trust bar on your website.

If I go to PayPal, I know I'm there because I expect to see a green bar.  That means something significant.  Call it a "racket", but they have provided a valuable service: I can be reasonably sure that I'm talking to the real PayPal without requiring me to understand ciphers.

I don't buy the idea that "who cares if the cert is self signed, the connection is still encrypted".  That's good against the casual packet sniffer, but isn't real security.  Because in that case, you're still vulnerable to man-in-the-middle attacks.  In such an attack, an attacker sits between you and a real site, presents his own self-signed cert that claims to be the organization you think you're talking to, and you accept it since it looks legit.  After that, the traffic is encrypted to the man in the middle, who views your traffic in plain text, re-encrypts the traffic, and sends it to the real site.  Not exactly secure, yet this can and does happen.

+1

nafai: I agree with your complaint. Having to pay money to get a signed key is madness. Browsers should handle self-signed keys better, and there should be a "web of trust" instead of a centralized "tree of trust" for verification. The current system of blindly trusting all SSL issuers is not exactly secure.

On the other hand, if you run a business site, it might be more profitable to pay a few $ in addition to your domain lease for a certificate even if just to put your customers at ease. This was the point of the OP and I also fully agree with that.

Exactly my point. Anything is better than unencrypted http, including self-signed certificates.  Yet self-signed certificates are highly under-utilized. As you said, too many sites offer no SSL at all.  Why is that?  BECAUSE THERE IS NO WAY TO OFFER SSL WITHOUT EITHER (A) PAYING THE PROTECTION RACKET, OR (B) PRESENTING ALL YOUR VISITORS WITH A BROWSER MESSAGE THAT MAKES THEM HIT THE BACK BUTTON FASTER THAN YOU CAN SAY HTTPS.

That should change.

Yes, I will rant about it everytime someone tells me to pay for a real SSL certificate (like this thread). There is no reason why I should have to, and so I won't, until/unless I operate a service that is so important/mission critical that it must be secure as possible. And then I will swallow my pride and pay the mafia, ahem, I mean verisign, and I will consider it a distasteful cost of doing business, like paying taxes or regulatory compliance.  Something you hold your nose and do even though you may not agree with it.

Until that time, I am just a little guy and have nothing stopping me from calling it like I see it.

+1, get a real certificate ffs.

Still, everything is better than plain text http. Too many sites still offer no SSL at all

This isn't the only inaccurate thing in your post but it's the most egregiously inaccurate, I think.

SSL has 2 different protections:  encryption and identity verification.

Encryption is certainly not worthless to typical end users, and self-signed certificates are an effective means of traffic encryption.

Identity verification is a separate issue from encryption. To say that self-signed certificates have no value because they don't provide identity verification is to ignore half the purpose of SSL in the first place. Actually, more than half, because I'd say that encryption is far more important than identity verification.

Yes, a lack of proper identity verification (like with self-signed certificates), can make you vulnerable to certain targeted attacks like MITM.

But unencrypted connections make you vulnerable to anyone who happens to be listening between you and the destination, the attacks don't have to be targeted at all.

A self-signed certificate is like me getting a bill in the mail "allegedly" from AT&T. How do I know that address to send payment to is really AT&T's address?  How do I know this bill is from AT&T at all?  There's no 3rd party that I trust saying this is definitely from AT&T. Anybody could have sent me a bill with AT&T's logo on it and their own address to receive my check.

However, an unencrypted connection with no SSL at all is more like me sending cash in the mail to pay that bill. Yes, chances are, it will arrive at its destination unimpeded. Yes, chances are, nobody's gonna hold that envelope up to a lightbulb and see that there's cash in it.  But the possibility is there, everyone between me and AT&T who handles that envelope could potentially see that there's cash in it and decide to take it for themselves.

Which do you think is a bigger risk?  Someone sending me a fake AT&T bill with their own address on it to send a check to?  Or sending cash in the mail?  Or if not cash, sensitive/private info like your username/pw or SSN or mother's maiden name or ATM PIN or whatever, written on the outside of the envelope for anyone to read who happens to hold the envelope in their hot little hands.

Yes, it's just an analogy, and all analogies are flawed to different degrees, this one is no exception the analogy isn't perfect.  But you get the idea.  I think it's far riskier to send sensitive information over the wire unencrypted than it is to allow self-signed certificates to pass without a big scary poison label on them.

I think perhaps the real problem is the dual purpose of SSL, trying to do 2 things with 1 solution.  There should be a way to provide encrypted connections without needing identity verification, and vice versa.

Oh wait, there IS a way to provide encryption without identity verification, it's called a self-signed certificate....  except that browsers have killed that possibility by making them sound more dangerous than unencrypted connections, which they categorically ARE NOT.  Every flaw with a self-signed certificate also exists with an unencrypted connection, including MITM attacks.  The vulnerabilities of self-signed certificates are a subset of the vulnerabilities of an unencrypted connection.

Another troll got out of the cage... this forum is getting better and better!

This is total bullshit.


That being said, there is no need for a backdoor anyway, when the Fed can just get issued a VALID cert for any domain.
Look through the CA lists that come as fully trusted with every browser download and tell me if you really trust everyone in there. At least with a self-signed certificate there is no way for someone to pose as your website.

Like it has already been said numerous times in this thread, the browser warning for a self-signed certificate really needs to change. A big red warning that takes several clicks to get past should only be displayed if a PREVIOUSLY ACCEPTED certificate changes. There is a Firefox extension that sort of does that already.

At BTC Alarm we totally agree, a certified SSL cert is the only way to go for any reputable Bitcoin related business.  Check out our article: Bitcoin and Site Security

Changing browser behavior is pointless, it is the correct behavior for the current state of SSL. Self-signed certificate are worthless to typical end users unless you have some sort of third party that can vouch for it. An average user has no way of verifying the certificate is issued by whom they intend to communicate with. This is a HUGE problem for wireless connections. The only way self-signed certificates would be practical is with a web-of-trust/plugin as some have linked in this thread. I haven't tried such plugins despite thinking they are a good idea and knowing about them, a regular user doesn't sand a chance evaluating a certificate.

i accept self-signed certificate fingerprints all the time, but I assume the servers I connect to have not been compromised and that I'm not being MITMed. To expect ordinary users to blindly trust a random certificate from a random server is reckless. At least with signed certs you have an iota of assurance which is much better than nothing, cost has nothing to do with the issue, there are free signed certs out there.

Complaining that signed certs are a protection racket and bringing conspiracy theories about snooping just shows you don't understand this issue as much as you think you do. If there are back doors I'll appeal to authority in the absence of any real evidence. Regardless, setting a higher bar is necessary, if you can get browsers to make self-signed certs idiot proof, then I might accept them as superior to signed certs, until that time it is reasonable to expect signed certs.

This is meaningless at all. Do you know exactly what are you talking about or this is "I heard something" statement?

All this "WARNING" stuff in browsers is funding by SSL-mafia "authorities". But in real world even signed certificates can be dangerous. If you are really concerned about your privacy etc. you should use something like this and, which is especially interesting, this.

SSL is worthless. The Feds (and the Fed) have backdoors in most modern SSL software that allows them access to it, and I am certain that some hackers out there probably have access to it as well.


Never, ever type your Social Security number, Credit/Debit card information, or real name into any website - only use them all at the DMV and retail stores.