Yes, Switching To HTTPS Is Important, And No It's Not A Bad Thing

from the we-need-encryption dept

Last month we wrote about Mozilla’s move to deprecate HTTP in favor of encrypted HTTPS, which followed on Chrome’s move to do something similar. What surprised me a bit was the response from many in our comments who didn’t think this was a good idea. People talked about how it added complications to development, or pointed to problems with the whole concept of trusting certificate authorities and a variety of other problems. Some worried about the costs associated with getting a certificate. Ben Klemens, who has written eloquently for years about the problems of software patents, wrote an article noting that this would make it difficult for individuals to easily set up their own web platforms, and require them to rely on a third party with whom you’d have to identify yourself (the certificate authority).

Of course, there are many attempts to deal with these issues, such as the big Let’s Encrypt project from EFF and others to offer free certificates. And, if you’re hosting websites online, you’re likely already going through a third party hosting provider, and it’s not clear how dealing with a certificate authority is really all that different.

But the most compelling argument I’ve seen for why this is so important comes from Eric Mill, who discusses why this is so important by highlighting the many, many ways in which the web has changed over the past few years — allowing both companies and governments to readily abuse the unencrypted nature of the legacy web, putting all of us at risk. This is a real problem that HTTPS goes a long way in solving:

But when I look at the last few years, I see a very different web than the one I was introduced to:

  • Verizon injects tracking headers into unencrypted traffic so they can sell your browsing activity to advertisers. This program started in 2012, after Verizon realized they “had a latent asset”, but wasn’t noticed until 2014.
  • Other companies like Turn piggyback on Verizon’s tracking header to sell your data to even more people, because they “are trying to use the most persistent identifier that we can in order to do what we do”, says Turn’s chief privacy officer.
  • Comcast injects ads into unencrypted traffic, because “it’s a courtesy, and it helps address some concerns that people might not be absolutely sure they’re on a hotspot from Comcast”.
  • Andreas Gal (Mozilla’s CTO, in his personal capacity) has claimed that Yahoo and Bing “can acquire search traffic by working with large Internet Service providers” to harvest users’ Google search results to improve their own — and strongly implies that they used to do this before Google shut them out through encryption. Even if you support better competition against Google, I doubt you expected your ISP to make deals to sell your traffic to other corporations without your knowledge.
  • The nation of India tried and failed to ban all of GitHub. HTTPS meant they couldn’t censor individual pages, and GitHub is too important to India’s tech sector for them to ban the whole thing.
  • The nation of China weaponized the browsers of users all over the world to attack GitHub for hosting anti-censorship materials (since like India, they can’t block only individual pages) by rewriting Baidu’s unencrypted JavaScript files in flight.

We discussed that last one last month as well, in noting how HTTPS would prevent attacks like the one China launched (and is constantly launching elsewhere as well).

And, also, it’s not just corporate abuse, but government/intelligence community abuse as well:

  • The NSA scans just about everything that goes through the internet backbones and saves as much of it as possible, in collaboration with intelligence agencies around the world. This is called “upstream collection”, and their “posture” is to “collect it all”.
  • The NSA’s upstream collection program has not been reformed. It will not be reformed by the current draft of the USA Freedom Act, in fact was endorsed by the only government agency whose job it is to review it, and the most meaningful court victory so far — while a wonderful and important precedent — addresses a separate program that only touches data about telephone calls.
  • After the Charlie Hebdo attacks, France is now making bulk internet spying explicitly legal and giving its intelligence services vast powers to work with ISPs to surveil the network.
  • The United Kingdom is likely to do something similar, after Cameron’s strong re-election means he can make good on his pledge to make all online communication subject to monitoring.
  • Pretty much everyone agrees that the security certificate system has its problems. We’ve been pointing that out for years. But encouraging more encryption now is solving real problems today. And, as Mill notes, Klemens’ and others’ concerns about this move towards HTTPS being a kind of “recentarlization” of the web are also misguided. All of those examples above show how big companies and governments are, themselves, abusing the unencrypted nature of the internet to take control and force a distributed system to act more like a centralized system by inserting themselves in the middle. HTTPS actually helps protect a more decentralized web by blocking those man in the middle attacks:

    When I look at all these things, I see companies and government asserting themselves over their network. I see a network that is not just overseen, but actively hostile. I see an internet being steadily drained of its promise to “interpret censorship as damage”.

    In short, I see power moving away from the leafs and devolving back into the center, where power has been used to living for thousands of years.

    What animates me is knowing that we can actually change this dynamic by making strong encryption ubiquitous. We can force online surveillance to be as narrowly targeted and inconvenient as law enforcement was always meant to be. We can force ISPs to be the neutral commodity pipes they were always meant to be. On the web, that means HTTPS.

    The security certificate system isn’t perfect. But an unencrypted web has serious and dangerous flaws that put us all at risk. In the old days, people could keep their homes unlocked as well, but that got widely exploited so now most of us lock our doors. It’s not perfect and it has problems, but the overall protection is worth it. That’s even more true online where encryption is important in enabling greater freedom of expression and protection of privacy.

    Filed Under: , , , , , , , ,

    Rate this comment as insightful
    Rate this comment as funny
    You have rated this comment as insightful
    You have rated this comment as funny
    Flag this comment as abusive/trolling/spam
    You have flagged this comment
    The first word has already been claimed
    The last word has already been claimed
    Insightful Lightbulb icon Funny Laughing icon Abusive/trolling/spam Flag icon Insightful badge Lightbulb icon Funny badge Laughing icon Comments icon

    Comments on “Yes, Switching To HTTPS Is Important, And No It's Not A Bad Thing”

    Subscribe: RSS Leave a comment
    Protector of the limit! says:

    Re: Re: Lies lies lies!

    Sad your just giving credence to GB = bandwidth and SSL take about double that means that all this text takes TWICE TWICE! as much bits to transmit and receive that is like 4 sqaure earth it’s like having 4 days every day…

    I’m trolling of course your right I posted it since 6 GB is a lot for mobile(CSB), but most Land line plans are unlimited or like at least 100GB, and yah I get it that Cell sites have bigger congestion issues but it’s still non sense, it’s not load balancing it’s made up reasons for billing, I used to work for an ISP and an they where paying $90/Mb @ 98th percentile and this was 2003 so.. bill me that then I will take you seriously about it being about network congestion!

    As for the the FBI TLS may be maybe ok but and maybe it’s a bit better than plain text but I still don’t trust it..

    I just do what i am told says:

    Re: Re: And held for "moderation"

    Yep I just do or in this case react to what I am told, I felt pretty stupid hitting submit when I could clearly see my second post but you have to protest when people start telling you your not allowed to speak even if they are not stopping you!

    PT boat on the way to Havana!

    DannyB (profile) says:

    Re: Re: Re: And held for "moderation"

    you have to protest when people start telling you your
    > not allowed to speak even if they are not stopping you!

    Nobody is telling you that you are not allowed to speak.

    But people can tell you to speak your mind elsewhere.

    I would immediately jump to your defense if I actually believed your freedom of speech were in danger. It is not. Your ultimate remedy would be to set up your own website and speak all you want to. Yes, really! Attract vast numbers of people from far and wide who want to come and hear your wiz-dumb.

    DannyB (profile) says:

    Re: Re: Re: And held for "moderation"

    His Brian also allowed him to write:

    > protest when people start telling you your
    > not allowed to speak

    Your never going too get you’re weigh on this.
    Their are just two many people out they’re using there words wrong too get to upset.
    Sew don’t loose you’re cool about it.
    You can sea mini common examples that exist of incorrect usage.
    People pick the write words two use according too there porpoises.
    But you’d have two be a fool to begin or end a sentence with the word “but”.
    And only an idiot would begin or end a sentence with “and”.
    And a preposition is a very bad word too end a sentence with.

    Rich Kulawiec (profile) says:

    Two counterpoints

    First, Lauren Weinstein has written about this here: When Mozilla’s Fanatics Make Us All Look Bad and I find myself in about 90% agreement with him. This move by Mozilla plays into the existing infrastructure for certificates and domains — and both of those are rotten to the core.

    Second, I find this move by Mozilla entirely disengenuous, given that it’s spent much of the past decade endlessly fiddling with the Firefox UI which was perfectly fine 30 revisions ago. It’s done that instead of implementing things that would actually protect users TODAY from some of the worst threats on the web: malicious scripting and malicious advertising. Instead those defenses have been relegated to Add-Ons (e.g. NoScript, AdBlock Edge).

    That’s wrong. They should have become part of the core functionality of the browser years ago. (And they don’t represent all the defensive functionality that should be in there: they’re just representative examples.) And implementing HTTPS won’t solve this because of course the malicious payloads can be delivered just as easily that way — and oh, by the way, can’t be filtered by sanitizing proxies that might otherwise prevent them from attacking users’ browsers.

    So, borrowing from Lauren: encryption is good. Encryption everywhere is very good. It’s mom and apple pie. But encryption via a forced march is a horrible idea.

    Anonymous Coward says:

    Re: Two counterpoints


    …and I can’t help but assume that – at least – nation-state adversaries have access to more than one root cert and therefore have no need to crack traffic encryption when they can just perform a simple https MITM. The PKI was a band aid to begin with and is almost certainly gamed at this point. The only real fix is to trash it and build something else from the ground up based on meaningful security.

    …and then all that’s left for us to do is address the security issues with the hardware, OS, firmware, addons, anti-virus, every other application installed on our machines, and the lawless state of affairs regarding the collection/storage/purchasing/selling/use of personal data.

    Commence breath holding in …3, …2, …1

    Lets Dance! says:

    Sorry to derail things!

    But there are problems with the whole CA infrastructure, and that it is that it’s paid, and it’s obvious that can be compromised buy what? your Kung-fu?!… no money so what do we do? I think think there have been several suggestions about distributed trust authorities, so I will ask what does techdirt think about these suggestions and would they support them both monetarily and programmatically?

    allengarvin (profile) says:

    There are lots of great arguments but...

    It remains costlier to scale because of the additional computational overheard of TLS. That’s still a fact in 2015. It’s not necessarily prohibitive, but it has to be taken into account. Load balancers acting as SSL proxies may need additional licensing, or a lot more cpu resources. CDNs charge more for it. And, worse, if you’re making that money back in ad revenue, advertising services can pay less when forced to use ssl (or, you might have to skip some sources because they don’t serve ssl ads and you don’t want one of those “some elements of this page are insecure” messages on your site).

    Bolrant says:

    Shills, shills everywhere


    Keep in mind there are likely paid shills from entities (commercial or government) with incentive to discourage people from moving to HTTPS. Be mindful of people purposefully derailing comments!

    HTTPS is worth it. It’s worth showing to website visitors/ customers that you’re trustworthy.

    Joe K says:

    Re: Shills, shills everywhere

    Two things:

    1. Your suggestion that certain institutional actors might attempt to
    influence a debate in particular fora covertly, with (eg) sock
    puppets, is not unreasonable on its face. It is, after all, common

    However, I would expect to see, in tandem with such efforts,
    overt attempts to spin the discussion as well. You know, like
    the FBI’s “OMG we’re going dark!!!” routine.

    Given your demonstrated alertness to shills. can you point me to
    anything overt like that arguing against the push to https, so that I
    can sniff at it myself for vested interest, straw-man arguments, etc?

    Anything at all. An editorial, or whatever, would be great.

    2. The following argument should raise alarm bells?

    We must do something.
    This is something.
    Therefore, we must do this.

    yall says:

    Yes, it is important, but no it is NOT to be trusted at the end of the day.

    HTTPS is a great step in the right direction. However, its centralized, ‘keys stored with another entity’ design means that it CANNOT be trusted in light of NSA’s known practices to infiltrate (or trivially hack) telecom companies, SIM card companies, and no doubt, certificate authority companies. To decrypt…EVERYTHING.

    If the NSA is your principal concern – then HTTPS simply must be treated like HTTP (though yes, it IS important to switch to it, as they are by no means the only adversary out there). Focus on knowing that your HTTPS session is ‘public’ (at least to them or other parties who can obtain ‘keys to the kingdom’), and thus what (and all that) you can do is *anonymize* what is public and in full view.

    HTTPS is not some panacea for all Internet privacy/security/anonymity woes – it is only something that ‘helps’.

    If the NSA is something I consider a threat (and it is), then I am only happy with personal information on the web being encrypted with a TRUST-NO-ONE form of encryption like Pre-Internet PGP or what have you.

    And no, I’m NOT missing out on a great deal (life’s stull of sacrifices and choices) – all public data and research is still easily within reach using powerful anonymizing technologies like Tor. (Hell, even Facebook has an official Tor .onion address!)

    And as for the loss of the benefit of online communication and the powerful things that can bring – well it turns out REAL conversations with REAL people using NO technology at all … is a WONDERFUL thing. 😀 In fact, there’s whole worlds of knowledge, information and community that actually AIN’T on the Internet anyway. 😉 The world’s bigger than the Internet, just cos the NSA currently ‘owns’ it doesn’t mean it’s your great loss!

    Lisa Westveld (profile) says:

    Troublesome certificates...

    Sure, HTTPS is better but it requires certificates to be linked to your domain. As a result, hosting multiple domains becomes more troublesome since every domain needs its own certificate. It becomes even more troublesome when you also need SSL for your subdomains.
    It adds a lot of maintenance for the webmaster who hosts multiple domains. You need to renew the certificates and you need to know what SSL is and how to use it. And how to debug any SSL-related problems. It is generally a huge pain in the donkey. (Well, other word for donkey, that is.) And you have to consider if it really makes customers happy.
    Client-side, same problem. When you create an app for the iPad and/or Android then using SSL requires a little more coding action. A little more knowledge that most seem to be missing.
    The biggest problem is that the lack of knowledge about HTTPS and SSL will increase the vulnerability of specific systems, not decrease them. Certificates get lost or fall into the wrong hands. And it still doesn’t protect you that well against a man-in-the-middle attack. Verizon could easily just intercept the HTTPS traffic, decrypt it and re-encrypt it with their own SSL certificate you your browser would not know about the “attack”. Actually, they can encrypt it and just send a copy of the unencrypted data to the user, so they will analyze the content that the user was looking for. It makes tracking a bit harder but they still know whatever person at address finds interesting.
    So, I think HTTPS just gives a fake sense of security. And Verizon including their own headers in the HTTP traffic should be a criminal offense. They’re violating Net Neutrality.

    nasch (profile) says:

    Re: Troublesome certificates...

    Verizon could easily just intercept the HTTPS traffic, decrypt it and re-encrypt it with their own SSL certificate you your browser would not know about the “attack”.

    Maybe I’m mistaken, but I don’t think that’s correct. Your ISP does not have the private key of the CA, so they could not decrypt the initial message. Then after that, both sides are using a secret key that Verizon also does not have, so again would have no way of decrypting traffic. Here’s a question about it regarding proxies, and as far as I know, an ISP would be in the same boat:

    They could use something like SSLStrip to change the HTTPS to HTTP, and then they would be intercepting HTTP traffic, but that would rely on nobody noticing that HTTPS connections aren’t really HTTPS – the browser would show it as unsecured. They could also use a fake certificate, but that would also be obvious. I don’t think they could do this covertly.

    So, I think HTTPS just gives a fake sense of security.

    It’s not perfect, but it’s real security.

    Some more info on MITM:

    Lisa Westveld (profile) says:

    Re: Re: Troublesome certificates...

    Verizon does not need the private key since they can use their own private key to encrypt everything again. The only way that you’ll notice this is when you check that public key that you’ve received. To prevent this, you would have to disable any Verizon certificate that’s on your own system so the browser will warn you. Basically, Verizon would use a proxy server and as administrator they can tell you that the proxy certificate is the valid one.
    You try to connect to a HTTPS site through the proxy. The proxy detects this and Connects to the HTTPS server by itself, thus receiving the public key that it needs for the communication between proxy and site. And Verizon would use its own certificate to sign the connection between user and proxy. And as a result, your browser will think it has a valid public key, which is true. The Verizon certificate is probably already in your store. But if you check the certificate, you’ll see it’s the wrong one!
    There is a solution, though, which I think is done by Google. In Chrome a few public keys are stored in the browser executable instead of retrieved over the Internet. Thus, the Chrome browser will know if it is talking to the true Google server or not over a secure connection. If the certificate it receives differs from the one it already stored, alarmbells will go off.
    And then the user clicks them away because users are generally not that smart…

    nasch (profile) says:

    Re: Re: Re: Troublesome certificates...

    So you’re saying they could, acting as a trusted CA, create a fake certificate for (for example), and sign it and certify it as belonging to Google? As far as I know that would work if Verizon is trusted by your browser, but man, I hope that is beyond the pale even for them. I mean that is way worse than the tracking cookie thing. After recent developments, I’m fairly confident the FCC would come down on them hard for something like that when they got caught – and they would.

    Kal Zekdor (profile) says:

    Re: Re: Re:2 Troublesome certificates...

    They could do that; as an ISP they could intercept any https requests, and act as a MitM proxy, decrypting and re-encrypting traffic in both directions. That would be troublesome if https was only about encryption. What they would not be able to do would be perfectly disguise the traffic as coming from the original source. They would need to automatically create certs for each site that a user requests. They could make these certs appear to be from the site in question, maybe even well enough to fool the browser, but they would not be identical to the certs provided by the site, and they would all be able to traced back to a single CA. When every https site in the world is suddenly using the same CA… Well, let’s just say people will notice, and there will be an uproar. See the Lenovo/Superfish fiasco.

    This type of MitM attack is untenable on a wide scale, particularly if you need to keep it quiet. Targeted attacks on less savvy individuals, however…

    Lisa Westveld (profile) says:

    Re: Re: Re:2 Troublesome certificates...

    Actually, some ISP have more or less made this happen already, but mostly to provide a better user experience for mobile phones. They would intercept all HTTP and HTTPS traffic and they would cache all large images on those sites to replace them with smaller versions for customers using their mobile phone to browse. This would reduce the amount of traffic but with HTTPS, they would have to become an in-between proxy and sign the traffic between proxy and user with their own certificate.
    ISPs have played with this option, noticed it “broke” the Internet and stopped doing it again. Nowadays, this is still possible as a special proxy so your mobile bandwidth is reduced.
    Since your provider is a trusted CA they could easily create their own certificates to use for this proxy and thus still capture all HTTPS traffic. Law Enforcement actually has the same option! And to protect yourself against it, you will have to check each certificate carefully before continuing browsing the specific webpage. That is, if you’re really paranoid.
    There are additional securities, though. The Chrome browser knows the public certificates for Google and other popular sites so it can validate against those. And it should be possible to have browser extensions that can do the same checks for you. It is also a good reminder for App builders to include their public key inside the app so they don’t need to ask for it from the web service. There are plenty of ways to detect these attacks and if Verizon would do something like this, like here on TechDirt.
    It is more secure than regular HTTP. But still, every security measure can fail and has weaknesses that can be exploited by parties willing to do so. With more and more sites moving towards HTTPS, it becomes more interesting to e.g. hack those certificates and recalculate the private key for all those public keys that are out there. It requires a lot of processing powers but it is not impossible. It is why we continuously have to find new and better encryption methods, simply because the old ones become too weak at some point in time.

    nasch (profile) says:

    Re: Re: Re:3 Troublesome certificates...

    With more and more sites moving towards HTTPS, it becomes more interesting to e.g. hack those certificates and recalculate the private key for all those public keys that are out there. It requires a lot of processing powers but it is not impossible.

    I’m not a cryptographer, but with modern encryption and good key sizes, I don’t think it’s as simple as just using a lot of computing power*. The people making this stuff aren’t stupid, and it’s a lot easier to increase the key size than to increase computing power by a proportional amount, so I doubt the security people are sitting on their hands while computer power overtakes encryption security.

    The obvious tinfoil hat answer is that government (NSA in particular) has far more computing power than is publicly known and can decrypt whatever they please, but I think some of the Snowden documents indicate that is not true. And if the NSA can’t do it, who else might be able to?

    * it’s possible not all current SSL implementations use good algorithms and keys, I don’t know.

    allengarvin (profile) says:

    Re: Re: Re: Troublesome certificates...

    “Verizon does not need the private key since they can use their own private key to encrypt everything again. The only way that you’ll notice this is when you check that public key that you’ve received. “

    No, part of the SSL verification process on the client side is verifying that the domain you’re going to matches the domain in an X.509 certificate (the CN in the Subject portion). Unless Verizon managed to acquire a certificate with as the CN, you’ll get a cert mismatch error on your browser.

    TLS is well-designed to prevent MITM attacks. Now if the MITM has the private key, that’s a different matter. Perfect forward secrecy prevents decrypting after the fact if the session is simply packet-captured. It’s not protection against a proxy when the evil party can redirect your traffic through it. And if the cert issuing process is compromised, that’s another problem. But people people notice when a CA can’t be trusted.

    Lisa Westveld (profile) says:

    Re: Re: Re:2 Troublesome certificates...

    As a CA, Verizon can create it’s own certificate and use it to sign a specific domain like Google or TechDirt. The certificate would appear to be legitimate for the browser since it is signed by an official CA and mentions the right domain. The fact that Verizon created it on the fly doesn’t really matter since it will look quite official. (Including any details found in the original public certificate!)
    To check it, you would need to check the certification path, which would differ from the original certificate. Without access to the original certificate to compare, you can’t know if you have the real certificate or a proxy version created by your provider.
    But if your browser or App has the original certificate included in the executable, it should be able to validate the certificate with whatever the site provides.
    Which only works as long as your browser or app gets updated when the certificate changes…

    allengarvin (profile) says:

    Re: Re: Re:3 Troublesome certificates...

    Yes, abuse of certificate authority is something that’s hard to protect against. That’s where we rely on the PKI infrastructure to audit CA issuing procedure–it would suck for Verizon if they were caught doing that, and Cybertrust’s root CA got revoked. Why would they risk it?

    Lisa Westveld (profile) says:

    Re: Re: Re:4 Troublesome certificates...

    They might risk it if they can somehow get away with it and if risking it would increase their profits. In the end, Verizon just wants to make profits so if listening in on HTTPS traffic provides additional revenue, they will certainly look at the risks involved.
    If they risk compromising their root CA then they could just make use of a different root CA by someone else. Or they will limit it to specific areas, countries or perhaps even their free WiFi, if they offer that somewhere.
    Revoking a root CA isn’t something Google or Mozilla will do that easily, since Verizon is big and powerful. The legal consequences might result in just a warning from Google and Mozilla and Verizon will reverse their changes.
    Providers in other countries might even have it easier. The Iranian or Chinese government could force all computer users to install a government-issued certificate that they can use to listen in on all traffic. The providers would then route all traffic through this system and the people might complain, but can’t do much about it. That’s the power of a monopoly.

    DannyB (profile) says:

    Re: Re: Re:3 Troublesome certificates...

    The day that Verizon abuses it’s CA power to impersonate websites is the day that some browsers, especially Mozilla and Chrome, will drop Verizon’s CA trust completely.

    That will suddenly mean that all of Verizon’s CA signed certificates look suspicious to millions of users.

    Suddenly everyone who ever bought a certificate from Verizon will get a new one from a different CA, and possibly sue Verizon for making their old certificate suddenly worthless.

    DannyB (profile) says:

    Re: Re: Re:3 Troublesome certificates...

    Which only works as long as your browser or app gets updated when the certificate changes…

    I would suspect that browser manufacturers are smarter than you think about this. Paranoid even.

    Here is my unproven hunch. Speculation. I’ll just use Chrome as an example. Google could use a private self-signed certificate that nobody else, including Verizon can impersonate. This self signed certificate is not from any CA. Google would have their own private CA. When Google’s Chrome browser communicates with the mother ship to get an update, it would check that the update is signed by a certificate from Google’s private CA. That way the integrity of updates is completely protected, even from a successful MITM attack against the existing CA infrastructure. The browser would not care that any other CA signed the download. Only Google’s private internal CA would be the one that your existing browser on your computer would trust to sign an update before it would be accepted.

    Very similarly I bet Microsoft (and Ubuntu, and others) use this approach to verify the integrity of updates to operating systems.

    If an OS or browser maker were really paranoid, they might build in a list of other apparently unrelated places to check for the availability of an update. That way, it is unlikely that Verizon could block the browser or OS from discovering the availability of an update. That way, the end user would soon be told that the update cannot be obtained because it is being attacked by an MITM.

    DannyB (profile) says:

    Re: Troublesome certificates...

    The biggest problem is that the lack of knowledge about HTTPS and SSL
    > will increase the vulnerability of specific systems, not decrease them.

    Making HTTPS and SSL more widely used will solve that problem. I remember when I first started using it in a commercial web application about six years ago. I had to learn a lot. But it was worth it.

    DannyB (profile) says:

    Re: Troublesome certificates...

    Certificates get lost or fall into the wrong hands. And it still doesn’t
    > protect you that well against a man-in-the-middle attack.

    Certificates can be revoked.

    There have only been two attempts at a third party abusing CA powers — and they were both detected early. The ramifications of the discovery were big.

    More and more parties are actively looking for MITM attacks. For example, even though Honest Achmed’s Trusty Certificates of Tehran Iran may be recognized by your browser, it would be a dead giveaway if they (or Verizon) were to issue a certificate.

    There is Certificate Pinning. There are browser extensions that people run to see what CA originally signed every certificate and notice if that ever changes and raise a red flag.

    Despite the imperfections of the CA system, it is a whole lot better than doing nothing. And it can be improved.

    Kal Zekdor (profile) says:

    Running a CA

    For anyone who is worried that using https will require trusting a third-party, there is a way around that. It’s not all that difficult to run a CA yourself, many Enterprises do so for encrypting internal web applications. Certs usually cost money not because of some technical cost of encryption, but because of the man-hours that are required for the CA to verify that you are who you claim to be. You can cut out the middle man by running your own CA (you implicitly trust you, right?). The downside is that the certs you create won’t be trusted by default (and the hoops you would have to jump through to do so are… untenable). Clients would need to install your root cert onto their machine, which is easy to do, and then any certs you create are trusted.

    If that’s too much to worry about, you can always forgo a CA entirely and use self-signed certs. No one will be able to trust them, but it’s the easiest way to get encryption running. The problem with https/ssl is it’s playing double duty as data encryption and identity verification. Providing encryption is cheap and easy, and solves most (though not all) of the concerns about modern web browsing. Unfortunately, encryption is caught up in identity verification/trust authority, which is difficult and expensive (though progress is being made on that front by EFF/Cloudflare/others). I’d love to see a protocol somewhere between http and https, that negotiates and encrypts traffic, but doesn’t rely on a trust framework. It obviously wouldn’t be as secure as https (MitM attacks would be much easier), so https would still need to be used for things like ecommerce, but it would be much better than http, and without the costs/difficulties of https.

    allengarvin (profile) says:

    Re: Running a CA

    “I’d love to see a protocol somewhere between http and https, that negotiates and encrypts traffic, but doesn’t rely on a trust framework.”

    It’s possible to implement TLS without X.509 PKI infrastructure. In fact, there’s an RFC out there that has an alternative, RFC 5081, which allows exchange of OpenPGP keys–this has been allowed since the TLS 1.2 standard (2008 or so); actually the RFC implies other types of cert exchange may be used if it’s explicitly negotiated, but 5081 is the only one I know of.

    As far as I know, no one has implemented it yet. There seems to be no interest in it.

    jim says:

    third party?

    Here’s a real cute one. I was refused a connection, thru to a military site, on https, I’ll explain my setup, I use google fiber, yes and yes, I know… Was looking for the availability to rent, during the upcoming holiday. Apparently the line has too many onlookers…yes, google feeds ads to help defrey the cost of maintaining the line,
    Here’s the only thing I don’t like, other businesses, don’t recognize that google is here. And its an active business, such as, you are trying to get the news or weather off an certain website, like CBS/NBC/fox, they all ask for a carrier that you are subscribed thru, to run the article thru? And pop you a list, usually not there..even on the locals, so I have to switch to the next big city that has coverage, they usually let me see the article?
    But that was the first time that happened, I get thru to my online bank, medical records, etc, but cannot check on the availability of a boat thru PS. Durn.

    Anonymous Coward says:

    More Profit for Shared Hosting Providers

    Projects like Let’s Encrypt are fine, but only those who manage their own servers can take advantage of them. Sites using shared hosting won’t have access to installing those certificates and most likely won’t know about them. Shared hosting providers make their profit by charging customers for every service they can market, and they usually have agreements with established certificate providers to offer their services to sites needing it, so it’s doubtful they’ll go out of their way to make it easy to use Let’s Encrypt and its kin. Shared hosting customers will either have little choice of what they can use or not know they can use free certificate providers, so they’ll be stuck paying extra costs that aren’t really needed. No matter how much you cry out “but the government is reading all our traffic and the ISPs are all evil!” it really isn’t vital to encrypt the cat pics on Aunt Marge’s personal blog, and to do so will now cost Marge an extra $10 or $20 a month.

    I’m all for making the entire internet https, but Mozilla’s method of doing so isn’t the best way. Instead of saying “do it our way or else,” they should be helping people make the transition by guiding them in the right direction, not forcing them at gunpoint. It will easily create a two-tiered system: those who are tech savvy enough to know what they’re doing, and those who are at the mercy of shared hosting vultures, and the latter will be the small start-ups and individuals who can least afford the added cost. I think when we come to the point where shared hosting providers start to offer SSL by default, then we’ll be ready to make the transition that Mozilla seems eager to push upon us.

    James Burkhardt (profile) says:

    Re: More Profit for Shared Hosting Providers

    So, rather then the slow, guided transition to requiring https by slowly restricting new, advanced browser features (most likely only used by the tech savvy) to https, you suggest they ‘guide’ web developers…how? I am already seeing a slow guided transition. I don’t see any solid advice in your post.

    James Burkhardt (profile) says:

    Re: Encourage, don't require

    If universal encryption is going to cause that, phone encryption has already done it. They already have the excuse. So we may as well protect ourselves against what we can. And tech companies and browsers have been passively encouraging HTTPS transition for quite some time. It hasn’t helped. So now they move to actively encouraging, by restricting advanced browser features to HTTPS connections. HTTP connections are still allowed, just not with the highest tech available.

    DannyB (profile) says:

    Re: Encourage, don't require

    We force their hands, making back doors to bypass
    > the encryption become mandatory.

    If that’s the way it must go, then that is better than what we have now.

    If we’re going to make back doors mandatory, then let’s get it out in the open in front of God and everybody. None of this sneaking around crap.

    That way, everyone can clearly see how their governments are acting and then judge whether it is in their best interests. That way, everyone, even politicians can see that it is them too who are being spied upon by the state apparatus.

    Anonymous Coward says:

    The OSI model was wrong

    Layers 4 and 5 are transposed. HTTPS is like putting gaffer tape on a sieve, that has been stacked on top of another sieve that is suspended over a black hole.

    The protocol stack is busted all the way down to layer 1. And it gets worse, since even the system bus has been compromised for some time. Not to mention the embedded exploits that come in the form of chipsets for video cards, disk controllers and NIC’s, which are there from the date of purchase. And that is before discussing the OS and application software based surveillance that is installed from new or on-demand via automatic update.

    In a nutshell, there isn’t a single part of consumer computer service that doesn’t need to be heavily refactored. But hey, we’re prefering SSL now, so Yay security! SSL is a turniquette on the gangrenous neck wound of a corpse.

    DannyB (profile) says:

    The most hilarious thing I've read all week

    I won’t try to refute it. To merely state it again is to refute it.

    Comcast injects ads into unencrypted traffic, because “it’s a courtesy, and it helps address some concerns that people might not be absolutely sure they’re on a hotspot from Comcast”.

    Ok, you can stop laughing now. Stop it! Stop it, I say!

    If I am concerned whether I am on a hotspot from Comcast, I need look no further than to check my download speeds, or whether certain protocols or even port numbers get throttled.

    Add Your Comment

    Your email address will not be published.

    Have a Techdirt Account? Sign in now. Want one? Register here

    Comment Options:

    Make this the or (get credits or sign in to see balance) what's this?

    What's this?

    Techdirt community members with Techdirt Credits can spotlight a comment as either the "First Word" or "Last Word" on a particular comment thread. Credits can be purchased at the Techdirt Insider Shop »

    Follow Techdirt

    Techdirt Daily Newsletter

    Techdirt Deals
    Techdirt Insider Discord
    The latest chatter on the Techdirt Insider Discord channel...