When I can self sign, and provide my CA by side channel (e.g. DNSSEC)
Then I'll go HTTPS more freely, but at the moment I don't feel the need to pay people
Google plans to reward websites that always use secure, encrypted HTTPS connections to transmit pages and exchange data – with a boost to their search rankings. The change is designed to promote improved online security in particular by encouraging developers to implement SSL/TLS (Transport Layer Security) to encrypt website …
Presumably you don't need a high google ranking. Otherwise, when an SSL cert is available for around $10/year it's a bit of a no brainer.
Encouraging the use of self-signed certificates is never going to happen. On a public facing website, their use only encourages users to blindly click through security warnings. Their only appropriate place would be where you have control over all the client devices so you can install your own certificate authority.
Much much more when you have multiple domains, wildcard domains, CDNs, etc in a business/organization. Plus the time spent/wasted coordinating with contractors and subs, explaining arcane bullshit, getting certs purchased, installation, configuring crazy old backend stacks to work with SSL, patching OpenSSL, downtime due to expired certs, etc, etc.
Browser's hoot when they see a new self signed certificate because there's no trust involved. Anyone could have made that certificate. If you rely solely upon such a certificate, anyone could perform a MITM attack, and your encryption is now worthless.
If you don't want the browser to spit fire when it sees such a cert, install the certificate on the client. If you can't install the certificate, the only way to obtain a benefit from a self-signed certificate is to have the end-user actually view the certificate details and confirm the fingerprint matches one which has been securely transmitted to them. And that's a whole lot of hassle to save a few dollars.
"Browser's hoot when they see a new self signed certificate because there's no trust involved. Anyone could have made that certificate."
Nit-pick: the *next* time you see that certificate you are assured that you are talking to the same person as last time, and with a certificate signed by a CA you are not assured that the person you are talking to is trustworthy, merely that they were prepared to splash the cash for that certificate.
If this is the first time you have visited the site and the certificate claims that it is owned by a big-name brand (and so the CA has a reasonable chance of detecting fraudulent registrations), then the conventional wisdom holds. Otherwise, it's more complicated.
"Plus the time spent/wasted coordinating with contractors and subs, explaining arcane bullshit, getting certs purchased, installation, configuring crazy old backend stacks to work with SSL"
Much of this is true but is not due to any problem with SSL but purely down to poor management, planning and organisation.
Expired certificates won't be a problem if you put reminders on your calendar when you issue/install them.
Chasing certficates isn't an issue if you have more than one person with access to your CA account etc.
"with a certificate signed by a CA you are not assured that the person you are talking to is trustworthy, merely that they were prepared to splash the cash for that certificate."
True but once fraudulent use of a CA issued certificate is discovered the CA can revoke the certificate, keeping end users safe.
If you click past the warnings and accept a self-signed certificate it's accepted forever (unless you know how to remove it which your average user doesn't)
I do realise that self-signed are worth the paper they're not written on; but that depends upon what you want to use the SSL for. If it's important or popular or user details are involved then you should do it properly. For small sites to protect login details; or for switching SSL on as an option 'just because' (mostly to avoid marketers tracking you and to make those bastards at GCHQ and the NSA earn their paycheques) then it should appear a little less alarming. I'd suggest maybe an orange or yellow padlock displayed in the browser toolbar (as opposed to the green ones for expensive certificates or whatever the colour is for the $10 special offer certs) that shows encryption is being used but you shouldn't necessarily be putting your bank account details in there. Possibly with a popup to alert you if the cert has changed since the last visit.
As things stand browsers react to self-signed certs like you're going to be imminently pwned and then fisted by terrorists. So nobody bothers.
Sure you run the risk of a MITM by someone faking the certificate; but sending everything in plaintext ALSO runs the risk of MITM, and requires less skill to do so.
The point is supposed to be ENCRYPTION of the traffic. Self-signed certs are perfectly adequate for that task, and should be accepted as such with no complaint.
Validation of a site's authenticity is an entirely different thing, and something Google are not testing for (at least, its not mentioned). really, setting up an encrypted link, and site authentication should be entirely separate, but the (so called) Certificate Authorities like to keep the two combined to force you to buy their rip-off certificates.
Just how many wildcard domains would you need? They're less than $100 a piece.
If you're running a business setup that requires multiple domains and a content delivery network for your customer facing side of things, I'd be pretty surprised to learn that you don't already have certificate management in place. Crikey, when I managed the business side of such things, I had every site SSL accessible a decade ago.
If your contractors cannot manage SSL configuration, you need new and competent contractors. This stuff isn't rocket science.
Not to mention, the price we pay for SSL certificate's "Trust" now-a-days is superficial at best when the US and their spy agencies controls most of the "authorised" (self-appointed) authorities.
Though mind you, the whole DNS is really just a gigantic money-making racket.
People can actually use alt-root and self-signed certs, it's a "simple" matter of getting the popular OS makers to import those certs by default into the OS. Not a chance of course, since again, they're all US based.
Their only appropriate place would be where you have control over all the client devices so you can install your own certificate authority.
That depends on how paranoid you are :-)
My email server tuns on my premises. I get my mail through a webamil interface.
My certificate is self-signed. If I'm on customer site and I *don't* get a certificate warning, I know straghtaway that they're intercepting my mail.
If I do get a warning, I can check the fingerprint against the one I carry in my wallet.
 This is incredibly rare, but it does happen.
"Encouraging the use of self-signed certificates is never going to happen. On a public facing website, their use only encourages users to blindly click through security warnings. Their only appropriate place would be where you have control over all the client devices so you can install your own certificate authority."
Hello - there is a really big clue in the title of my post, let me just quote it for you:
"and provide my own CA by side channel"
There would be no security warning, and rather than trusting some Iranian cert authority I've never heard of I'd be asking you to trust, for instance, the DNS root cert - which feels alot safer to me.
The root cert signs the country cert which signs my domain cert which signs my "SSL CA" record.
The SSL CA is then trusted within that domain, so I can use it to authenticate my website, and the encryption comes for free.
I can update my CA on a daily basis if I'm paranoid, or more likely an annual basis
One of the advantages I see to this scheme is it makes black hat SEO bullsh*t just that little bit harder. The economics of linkfarming and SEO spamming mean even small incremental changes in cost have large knock-on effects that can undermine the profitability of the enterprise.
If we start accepting self-signed certs, then all that will happen is linkfarms will start using SSL with self-signed certs. And the consequence of accepting self-signed certs are potentially quite troublesome. I'm not down with making MITM attacks easier, for example.
Ideas like changing the color of the padlock for self-signed vs. CA-signed certs don't stand well in a world where it's hard enough to convince folks to look for the padlock in the first place. And unlike some IT-savvy people I've met, I don't believe that users who are less savvy deserve to get hijacked.
Hmmm... Methinks this would be a good way to suck up more IPv4 addresses and push more toward IPv6 (not really, but hey, it's Google). It's too bad we can't just all assume that SNI will work everywhere, although with the "death" of Windows XP, there should be less resistance, in theory.
Irony alert: When the Heartbleed bug was discovered, you would have actually been a little safer to NOT be using SSL, as you wouldn't have had the potential for private keys to be stolen and allowed a third party to impersonate your site over a secure connection (although nowadays, I'm sure a large percentage of netizens don't pay as much attention as they should to whether a connection is secure or not).
I'm wary of the dominant search leader using their power to push any agenda or apply their choice of discrimination. On the other hand, this will do more to get site owners actually using SSL than anything else has ever managed to do.
Also, certification is one Hell of a racket - massive fees for an infinitesimal amount of processor time and a modicum of bandwidth. I suppose security protecting your private keys is not cheap, but I can't believe it costs so much to justify this. We need a different CA infrastructure, one that is less of an exclusive club.
But good security *is* expensive, as that Dutch CA that got hacked proved.
Also 'less of an exclusive club'? Have you seen just how many CAs your average browser accepts? Any one of them can be hacked and used to spoof a genuine HTTPS site. Fewer dodgy CAs might not go amiss. Fewer under the control of five-eyes and dodgy BRICs might not be too bad an idea.
OK, regarding the BRICs it seems that at least Brazil seems to be on the receiving end of these shenanigans...
"Proofpoint’s researchers have observed that most websites were slow to enforce the use of HTTPS because the encryption it uses to secure the connection slows down the web experience..."
Are they saying their researchers regard using HTTPS as significantly or just that the webmasters' perception is that it will slow their site down so they don't so it.
Overall, I would expect that https is unlikely to have any noticeable different to any modern webserver, unless Proofpoint know different (and this is now showing as a sub headline for this story "Er, what about latency, bro?")
>>Overall, I would expect that https is unlikely to have any noticeable different to any modern webserver,
I did some benchmarking on a site I oversaw the development of for a client once. I couldn't notice any difference in load times when I swapped the site over to be exclusively HTTPS nor did I bother trying to. Honestly, the amount of variables involved, any difference is just lost in the noise. I did measure the hit on processor load on the web servers and found an increase of about 2-5% load, iirc. So there's a slight hit there, but trivial imo. But that was also a case where it was all being handled in software. A serious setup would have network cards with dedicated hardware built in for SSL. And that would move it down from something you might conceivably have to account for in edge cases / massive set ups, to something not even worth tracking.
The real cost of using SSL is paying the certificate authorities. That can get pretty pricey.
>>"Is it necessary to use HTTPS on say, my pet poodle Foofie's single page website if it's just a bog standard HTML page?"
Well, it is now, or Google will push you down the rankings. ;)
Other than that, the answer is no. Unless you are concerned that others will try to fake Foofie's web page and direct visitors to the wrong one.
No, it isn't necessary to use SSL on sites which do not have logins. But it is the friendly thing to do. Part of the point is not just to protect your traffic, but to move to having most Internet traffic routinely encrypted to make the job of hoovering up all data by tapping backbone links harder. It also reduces the chance for the spooks to say "ah, his data is encrypted -- he must be a terrorist".
And, it makes it safer when you later decide to add a hidden page to Foofie's web site to make the Anarchist's Cookbook available -- no one can watch your traffic to see whether people are reading the poodle's page or the secret page.
millions & millions of websites rely on shared hosting, but unless you pay through the nose certs apply to a single server.
This benefits the data center providers, who'll be making a fortune renting out VPS instances, and the certificate providers, unless people don't mind seeing the garbage urls if you use the shared server's cert.
Of course you can have two domains on the same server both running SSL each with their own certificate, it's done regularly and if you were an ISP then you would expect to know this.
In reality though anyone using shared web server hosting (not including VMs in that obviously) is unlikely to have a serious enough web business that the difference in the search rankings that this would provide would be of concern.
>>"It makes no sense to me that browsers treat a self-signed certificates as worse than no encryption at all. It still protects against passive eavesdropping, isn't that better than nothing?"
It is better than nothing at all in a technical sense. But if it introduces a false sense of security that could be worse. An incorrect certificate is a major warning sign. If a browser takes a self-signed certificate as just a lower-level of security, it would be quite easy to pass along a fake certificate and the browser will just shrug and change the icon from green to orange or whatever - something a user will have become habituated to ignore through all the cases where self-signed certificates were legitimately used.
To counter that, you'd have to check every self-signed certificate you got against all CAs just to see if they actually had a legitimate alternative registered with them. And whilst I haven't thought that through, I can already think of some significant attack vectors that would open up.
But to use the same argument, most users probably wouldn't notice if they suddenly found themselves on a completely insecure site. Shouldn't the browser throw up a series of scary looking dialog boxes every time you visit any http site? I mean to be honest I might look for the lock icon the first time I buy something on a new site (before entering CC details) but that's about the only time I think about it. I doubt I'd really notice if I somehow got sent to a perfect replica of Amazon only it was http.
It isn't the fact it is self-signed that is the warning, it is the fact that it is from an untrusted authority. You can self-sign certificates using your certificate manager and trust the certificates on your domain and you won't get the warning.
The warning is stating that the certificate isn't from a trusted authority and therefore should not be trusted, hence the certificate trust model is broken and this is a situation that requires yuor attention - there is a significant security risk!
The only reason you think it is less of a security risk than having no certificate is because you know that you put that self-sign cert there in the first place. The browser doesn't know that you know it but will allow you to ignore it in the future. However if you access mybank.com and a very simple DNS redirect has taken you to a different server which uses a self-sign certificate but no warning is given then that is a major issue - the browser didn't even inform you that this site is using a certificate from an authority that you don't trust.
Eventually, if you look at the way this is going, you may find that any site which doesn't use SSL will also give you a warning when you access it...
I'd like to see more ubiquitous use of SSL for regular websites, personally. For one thing, it gives cover to more sensitive use of SSL (instead of "this bit of traffic is SSL, so it must be the important stuff"); moreover, it defeats stupidity like Phorm and TalkTalk's recent URL snooping (where any time a user requests something over TalkTalk, TalkTalk fetch themselves a copy 30 seconds later - breaking stuff like WebSocket implementations, as well as being distinctly creepy).
Imagine an Internet where only the sender and receiver know the content of each message: anyone else can only see the size and endpoints. Isn't that worth a bit of CPU overhead at each end?
"Making web connections secure by default is an effective defence against man-in-the-middle attacks as well as offering privacy benefits to surfers. Many web giants are already going https-by-default in response to ongoing revelations from rogue sysadmin Edward Snowden"
What problem are we trying to solve here?
If we are just trying to make life hard for people spying on-the-wire then this is overkill and discriminating against small websites.
It is all very well for Google, Facebook, etc but the majority of websites are on shared servers without dedicated IP addresses. It makes perfect sense to encrypt everything going to and from a high value target like google.com but for the rest of the world there just aren’t enough IP addresses to go around and plenty of small but useful websites that are never going to have a certificate.
If the problem is that all communications are in the clear and therefor wide open then let’s obfuscate them. AES256 with snake-oil certificates sounds good to me but I bet ROT13 looks pretty similar at first glance – and if you are trying to spy on everything then first glance is the only one you are going to get.
When using HTTP (not HTTPS) my browser still manages to optimise connections – connection:keep-alive. If it sees “connection: close” it doesn’t display a red alert and tell me to “Run Away!” So why can’t my browser quietly and unobtrusively try and obfuscate my data if both ends of the connection support it?
It seems to me that the man-in-the-middle thing is probably an advantage as corporate proxies and CloudFlare will still work. I mean none of us are against targeted surveillance against real baddies are we? Installing a tap on a deep ocean cable is one thing but I bet that running a proxy-to-everything in the middle of the Atlantic would be quite another thing.
I won’t believe Google are trying until I see Chrome and Google-Web-Server both do something like this...
User requests "http://example.com/home"
Client requests "http://example.com/_obfusticated-content"
Possible results are YES, NO, NOT-NOW (reason)
For NO and NOT-NOW the browser requests "/home" in-the-clear
For NO the browser remembers the results and doesn’t try "/_obfusticated-content" again
For YES the client and server do a key exchange and the conversation disappears down a deep, dark hole.
You know what I've realized after reading all these posts? That registering a certificate should be something that you get as part of registering a domain name. And when you transfer a domain name's ownership, the old one is invalidated.
Yes, not everyone is going to need it and you may not have created it at the time you register the URL, but it should be standard and considered a basic part of buying a domain, included in the cost.
Certs shouldn't be a big expense and something people think of as an option when needed. There's no big technical difficulty with them, just the issue of keeping the signing certs of the CAs safe. And they would make just the same money (more probably) if the cost was a few pennies on every domain purchase or transfer rather than occasional big purchases.
That's how it should be.
>What problem are we trying to solve here?
Determining quality sites from crap sites.
If there are two tech news sites and one has an HTTPS cert then it probably has a proper sysadmin and is professionally run while the other is probably just recycling press releases and running spammy ads
Is too expensive for a personal blog.
And last time I check, personal blogs still contains some of the best content there is on the internet.
I hope Google consider that, a lot of people in the world don't particularly like to spend pointless money here and there just to get their search ranking up.
Several French hospitals, and KFC (France). Hook up to their WiFi and try to go to an https site, Safari pops up a request for an SSL certificate that is completely different to the one you expected to see. So while Google is pushing us towards greater security, some hotspot providers (no doubt in the guise of "protecting" us/children/profits) are intentionally smashing down said security.
[kudos to McDonalds (France) and Buffalo Grill, who not only leave https alone, but also permit a VPN to be used so you can fetch mail and stuff without other people snooping....which is supposed to be why ssl on an open AP is a good thing, right?]
Let’s start with the CDN problem. If you are a large online presence, eg Google, Facebook, then you have your own CDN and all is well. BUT most online presence is channelled through a 3rd party CDN, eg Cloudflare, Akamai. The SSL trust model is understood by many to mean that there is end-to-end encryption between you and the organisation that you are communicating with. Instead the CDN is decrypting and inspecting all the traffic before deciding whether to forward the request to the origin or not - this is MITM as the CDN is transparent to the vast majority of users.
Next, let’s consider when a browser alerts a user to a fraudulent certificate. This alert only happens if the issuer of the certificate does not have a valid trust relationship with an 'installed root CA'. There will be no alert if the certificate for www.facebook.com has been issued by Digicert Inc (as my browser currently reports) or, say, Comodo. I.e. your browser isn’t normally checking the actual authenticity of the certificate, just that it has been signed by any 'trusted CA’ (and has not been revoked).
So who are all these organisations in this list and can every single one be trusted to maintain security (ala Diginotar) or even be a real certificate authority? If Snowden is to be believed then many of the entries in the list are governments or surveillance groups and if you are on the list then MITM becomes almost trivial.
Until this situation is fixed then HTTPS ensures that the transport is encrypted but offers no gaurantee that the two end-points are what you the client believe them to be so using this as a criterion for URL ‘goodness’ is fundamentally flawed - you are paying your $10 (or more) just to get a better ranking in Google and some large organisations obviously don’t see the point.
1. https://www.theguardian.com - 443 gives 302 to 80. (Until recently, this give a certificate error, xxx.fastly.net, ignoring proceed to a 404)
2. https://www.telegraph.co.uk - 443 gives a cetificate error, xxx.akamai.net, ignoring gives a 301 back to 80
Biting the hand that feeds IT © 1998–2020