Bitcoin Forum

So I just clicked on this link: https://glbse.com/forum/viewtopic.php?f=15&t=24

glbse.com has apparently been around for a few weeks/months now...

Why am I being warned about their potentially untrusted internet connection?

It costs literally $2 for a valid SSL certificate when you purchase a domain through namecheap (which is a very competitively priced domain name registrar).

Check out the "PositiveSSL Addon" for only $1.99 or something like that and be done with these "untrusted connection" warnings.

For proof, just click on the "bitcoin mining tutorial" link in my signature. Only cost me $2 for that https.

I guess my question is why are so many of you forgoing it? It REALLY throws up a red flag to anybody potentially thinking of investing money... although you (the developers) might be oblivious to this if you simply press "add exception" and keep on trucking.

I agree, it only costs 8.95 or something like that on cheapssls.com (or cheapssl.com I really do not remember). You have to buy a domain through namecheap.com to get the 1.99 pricing I think, so cheapssl.com is also a great site to get standalone certs.

You know, there's no reason for people to think of it as a red flag, because it really isn't a bad thing per se. The security comes from the fact that the communication with the server is encrypted. It doesn't matter whether the certificate is valid or not. Browsers throw up that warning for all self-signed certificates for example. It throws up the warning anytime you have a certificate that isn't on their approved "certificate authority" list, aka the SSL mafia protection racket.

The only security having a valid certificate recognized by browsers gives you is that you know who you're talking to (i.e. which website you're on). Well, sorta.

You see, if I type in https://www.paypal.com/, I get to see an SSL certificate from a trusted authority that tells me, "yep you are on the paypal website and your connection is encrypted". Great!

If I type in https://www.paypal.com/ and they have a self-signed certificate or a certificate issued by someone not on your browsers trusted certificate authority list (lots of places, especially small one-man dev shops, sign their own certificates to save money), the connection is still encrypted. It's just that I have no guarantee I am on paypals website. Except I do have a guarantee, I typed in paypal.com (hopefully). Of course, some people google search for "paypal" and then click on it.

If I type in https://www.pay-pal.info/ or some such, it might present me with a valid certificate!  Saying "congrats your connection is secure and we verify you are on the pay-pal website".

Except the pay-pal website may not be the paypal website. Ignorant people won't know the difference between paypal's real website and SSL certificate and a knockoff's fake website and fake SSL certificate.

So you see, the only real security you get from SSL is the fact that it's encrypted, not the certificate. That's why lots of people self-sign their certificate, because then you can implement SSL for free instead of having to pay an annual fee (which is per domain, so it can add up for those of us with lots of domains).

Yes, I completely agree that the browsers throw up this big scary message whenever the certificate doesn't come from one of their approved "authorities", and that's a bad first impression for your customers. But I also don't like complying with the protection racket just because it's the simplest solution. It may be easiest to just give the bully your lunch money but that doesn't mean I won't fight for alternatives.

You can direct first-time visitors to your non-SSL site so they can get to know you first, before you put them through the SSL. You can have a page to specify precisely why you use a self-signed certificate (lots of people do). Or, in my mind the ideal solution would just be for browsers to stop verifying certificates at all. There should be no warning message, unless there is a problem with the encryption itself. Your connection should either be SSL-encrypted or unencrypted, the browsers should make no attempt to identify whom you're connected with.

I post a lot on hacker news, google dev forums and the like. A lot of people think like I do, and I make every opportunity to push browser devs in this direction (or at least remind them about it), especially my favorite one Chrome. But in the meantime, I am not gonna get an "official" SSL certificate any more than I am going to pay the BBB for their own version of a protection racket.

A little tip from me.

You can get free SSL certificates from startssl. Its only Class 1 and you have to 'reactivate' it every year but it is for free.

I use that service since years without any problems.

Try explaining that to the average Joe.

If my mother was doing her banking and her computer told her "WARNING! UNTRUSTED CONNECTION!" should would probably call me up ASAP in a half panic.

a number of people have raised this to Nefario, myself included. he was initially reluctant to use a signed cert but he has conceded that using a signed cert is something that needs to be don. after making that decision, he said he was having trouble getting a signed cert while he was living in China, but now that he is in the States I'm sure it's on his to do list after settling down and taking care of some more pressing issues with service.

I understand that, and that was kinda my point, though I now realize I didn't explain myself very well despite being quite verbose.

What I meant to say was, I think it would be better for people to try and convince the browsers that they shouldn't warn about self-signed certificates, or should provide a much more friendly warning, rather than to get every website on the planet an official SSL certificate and have them pay annual fees for the privilige.

The friendly browser warning for self-signed certificates, or expired certificates, or any certificate issues by a non-trusted authority (trusted by the browser) could be something like: "Warning: The security certificate for this website is expired or unknown. Your connection to this website is still encrypted, but the website's identity cannot be verified. This is not necessarily a bad thing; some websites use their own certificates to encrypt traffic without identity verification. It is incumbent upon you to make sure you are at the correct website, but rest assured that your traffic with this website is fully encrypted."

Or something.

Of course, I recognize that convincing browsers to change their standard operating procedure is extremely difficult and not likely to happen anytime soon. Thus I recognize that in some instances, it's much better for a website owner to just swallow hard and pay the protection racket. A financial services website or exchange, for instance, had better have an "official" certificate.

HOWEVER: There is a niche for websites that could benefit from encryption but don't require an "official" certificate. Furthermore there is already a tool for accomplishing encryption without "identity verification from a trusted certificate issuing authority": using a self-signed certificate, or a free one that isn't from one of the standard authorities. However, browsers warnings against untrusted certificates, as you pointed out, can scare off a lot of people, so despite this solution being in place and completely functional, we can't use it because of the scare factor. That is what I am lamenting! That is what I think should be changed, and should be a higher priority than telling everybody and their mother to get a "real" certificate. I think it's just too damn bad because I would love to encrypt traffic to some of my more sensitive websites, but I'm not gonna pay the mafia for the privilege when the technology is available for me to do it myself and for free. And for all the thousands of websites that NEED the "image" or "trust" of being "official" (like banks, exchanges, or deep pocket websites like facebook), there are MILLIONS of websites that could benefit from encryption but can't do it because it's got a faulty poison label on it.

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.

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 (https://blog.torproject.org/blog/detecting-certificate-authority-compromises-and-web-browser-collusion). If you are really concerned about your privacy etc. you should use something like this (https://addons.mozilla.org/en-US/firefox/addon/certificate-patrol/) and, which is especially interesting, this (http://www.networknotary.org/firefox.html).

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.

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 (http://blog.btcalarm.com/post/7943190104/bitcoin-and-site-security)

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 (https://addons.mozilla.org/en-US/firefox/addon/certificate-patrol/) that sort of does that already.

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

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.

+1, get a real certificate ffs.

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

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.

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.

+1

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.

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

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

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.

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.

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

Try...

https://glbse.com

now...

http://s1.postimage.org/2a10fzqro/glbse.jpg (http://postimage.org/image/2a10fzqro/)

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

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.