Netflix Moving To Encrypted Streams, As Mozilla Moves To Deprecate Unencrypted Web Pages As Insecure
from the yay-encryption dept
We’ve been pretty vocal about supporting the encryption of more and more web traffic. It’s important for a variety of reasons, not the least of which is your privacy and security. A few months back, we were excited to see the Chrome security team suggest that it should start marking unencrypted web pages as non-secure. It appears that Mozilla is now joining in on the fun, proposing deprecating unencrypted HTTP web pages to encourage more web developers to go full on in support for encrypted HTTPS:
In order to encourage web developers to move from HTTP to HTTPS, I would like to propose establishing a deprecation plan for HTTP without security. Broadly speaking, this plan would entail limiting new features to secure contexts, followed by gradually removing legacy features from insecure contexts. Having an overall program for HTTP deprecation makes a clear statement to the web community that the time for plaintext is over — it tells the world that the new web uses HTTPS, so if you want to use new things, you need to provide security.
It’s a clever setup. Basically, if you want to take advantage of new features on the web, you’ll have to encrypt.
Meanwhile, it appears that Netflix has separately announced that it is moving forward with plans to encrypt all of its infrastructure with HTTPS to better protect your privacy as well:
with our existing server infrastructure and the up to 50% capacity hit we had observed, driven by our traffic mix.
At that time, we were uncertain of the gains we could achieve with software and hardware optimization and of the timescale for those. I’m pleased to report we have made good progress on that and we presented our FreeBSD work at the Asia BSD conference. We now believe we can deploy HTTPS at a cost that, whilst significant, is well justified by the privacy returns for our users.
So, as we mention today in our investor letter, we intend to roll out HTTPS support over the coming year – for both our site and the content itself – starting with desktop browser tests at scale this quarter.
In short, yes, deploying HTTPS at that scale is expensive, but the benefit to users is tremendous and worth it.
It’s still going to take a while, but we’re getting closer to reaching that tipping point where an unencrypted web is a historical anomaly and that’s a very good thing.
Filed Under: encryption, https, security
Companies: mozilla, netflix
Comments on “Netflix Moving To Encrypted Streams, As Mozilla Moves To Deprecate Unencrypted Web Pages As Insecure”
Development
I can see an issue here: development environments and internal operations where by design it’s not necessary to verify the endpoint’s identity or secure the content from eavesdropping, either because the client and endpoint are on the same machine via 127.0.0.1, because everything’s running over a VPN that handles the encryption or because they’re on a secured network where if an intruder’s in a position to spoof an endpoint or eavesdrop on traffic you’ve got far, far bigger problems than HTTP traffic to worry about.
Especially when I’m developing software I don’t want to add SSL and it’s complications to the mix yet. I have enough bugs without adding SSL certificate issues (including such fun as “I can’t get real SSL certificates for the domain, security policies on the systems prevent me from adding a local root CA certificate and bits of software don’t have the ability to handle self-signed certificates without errors.”) and having to correctly configure SSL on both ends before I can even start seeing output.
I’m strongly of the opinion that protocol layers should be independent. HTML shouldn’t depend on features of HTTP nor require that it only be served over HTTP. HTTP likewise shouldn’t care whether it’s running over TCP or SSL or SNA for that matter (yes, even in this decade good old LU6.2 and SNA over bisync is alive and well despite all attempts to correct the situation).
Re: Development
I don’t want to add SSL
Unfortunately, there are a lot of developers that would prefer not to add SSL and HTTPS. That’s why Mozilla is proposing what it is.
Re: Re: Development
Notice that I said “yet”. I definitely want to add it, but not when it’s just running on my local workstation or on the developer network and I’m trying to get the code itself working. One thing at a time.
And what are they going to do with IPv6 and built-in IPSec, where the authentication and encryptiong are handled at the IP level rendering SSL/TLS redundant? IPSec is an RFC-level standard, after all.
Re: Development
I’m strongly of the opinion that protocol layers should be independent.
Yes. They should. That’s arguably one of the reasons why the Internet’s protocol layers are what they are and not something else. It is a serious architectural error to introduce dependencies between them — or between network data transport protocols and content.
It’s also a dubious idea to push for even more reliance on the CA model when (nearly) every day new research results show that it’s coming apart at the seams.
There are far more pressing things for Mozilla to work on than this. The functionality of add-ons like AdBlock Edge, NoScript, BetterPrivacy, Disconnect, etc. all need to be in the browser — because those address some of the most significant threats. Reliance on Adobe Flash needs to be phased out. Ports to other architectures need to be prioritized. (One of the best ways to find bugs in your code, security and otherwise, is to get it running on another CPU/operating system.)
And geez, PLEASE stop the endless, pointless, silly tinkering with the UI – which was perfectly fine 25 revisions ago.
Re: Re: Development
“That’s arguably one of the reasons why the Internet’s protocol layers are what they are and not something else. It is a serious architectural error to introduce dependencies between them — or between network data transport protocols and content.”
By that logic, https should removed from browsers.
Re: Re: Re: Development
No, it’s not. Try again.
Re: Re: Development
And geez, PLEASE stop the endless, pointless, silly tinkering with the UI – which was perfectly fine 25 revisions ago.
And geez. PLEASE stop the endless, pointless, silly tinkering with wireless technology – my home phone was perfectly fine 40 years ago.
The most important innovation comes from people doing pointless tinkering.
Re: Re: Re: Development
Pointless tinkering on the workbench or in the lab is indeed a wonderful thing.
But when it’s applied to UI design of production software and inflicted on hundreds of millions of people, it’s not. Mozilla’s developers have only succeeded in making the UI far less useful than it was and in penalizing competent users. Meanwhile, serious security and performance bugs remain unaddressed — have you looked lately? (where “lately” could be any time in the past several years)
Re: Re: Re: Development
Re: Re: Development
There are a number of add-on features which should be part of the browser to begin with, I agree (like control over favicons for example). It’ll never happen though, not so long as they remain wholly obsessed with memory usage and speed. They’ve done so much damage in pursuit of that goal that we’ve lost a number of good add-ons as a result. Mozilla never seems to notice or care even if they do, though. This makes me very sad.
Re: Re: Re: Development
It’ll never happen though, not so long as they remain wholly obsessed with memory usage and speed.
If this is what happens when Mozilla is obsessed with memory usage, I would hate to see what it would be like if they didn’t care. Or did you mean they’re obsessed with using as much memory as possible?
Re: Development
I fully agree with your allowing development over clear text, but no internal operations should ever be allowed in the clear.
I work in a company governed by PCI-DSS, so maybe my perspective is skewed, but there is always the possibility that new temp worker is going to try an snoop your internal network. No network traffic is safe unless you have endpoint encryption.
BTW, for local SSL/TLS go to a free cert provider and get a cert for something like localdev.[your domain].com, then in your host file (or internal DNS) point localdev.[your domain].com to 127.0.0.1. Now you can make requests to your local system with a cert signed by a trusted root.
Re: Re: Development
A temp worker is going to snoop on your localhost traffic over the network?
Re: Development
I don’t think every JOE SCHMO web page should have the same access to HTTPS webpages and sites I have had secure transactions on, so they should not be the same HTTPS secure protocol as those with which I do commerce.
Re: Re: Development
I’m not sure I understand what you’re saying here, but I’ll ask anyway — why do you think that HTTPS should not be used by sites that aren’t engaging in commerce?
HTTPS will do little good if the FBI and NSA directors, James Comey and Mike Rogers, demand a front-door/side-door/back-door/open-window into HTTPS encryption.
Why should I trust corporate root CAs? What exactly bestows this magical trust sauce on these corporate entities so easily susceptible to forceful state coercion? They’ll swear on Turing’s persecuted soul?
Re: Re:
Propose an superior alternative solution that doesn’t have such trust issues, and collect your fortune when people use that instead.
Otherwise, this is really the best solution visible at the moment. Don’t trust the CAs? Fine, then your default position is “do not trust”, which is what it already should be for unencrypted sites now. Literally nothing has changed for you if you don’t trust the CAs.
Re: Re:
Recent events have show that at least some of the companies supplying web browsers are going to drop CA’s when they look like they cannot be trusted.
Given there is competition in the browser market and people care about privacy, CA’s that can’t be trusted are probably an issue that will be resolved by market pressure.
Re: Re: Re:
Just think of the chaos if a CA with millions of individual clients is dropped.
Re: Re:
“Why should I trust corporate root CAs?”
These preloaded root CAs are a security compromise. They weaken the trust mechanism quite a lot, in exchange for the convenience of not having to verify the trust chain yourself. So your concern is quite valid.
My answer to the problem basically boils down to… yes, it’s suboptimal, but it’s the best we have right now. If you require a greater level of security, nothing stops you from doing it the proper way: remove the root CAs and validate the site certs yourself. You can then sign those certs with your own root cert (that you’ve installed in your OS and/or the browser) and everything will work as normal.
Re: Re: Re:
That sounds like a nice idea, although the certificate maintenance for hundreds of websites is significant, as is the trust issue on certificate modification/renewal, but… what’s the benefit of that method as opposed to certificate pinning?
Yeah, I’m with AC on this one. The (main) problem with requiring SSL is, certificates cost (a lot of) money, and there’s a semi-monopoly on them. It increases the cost of starting a website, which hampers innovation.
But then again, if SSL becomes more and more the standard, maybe there’s greater incentive to fix this issue. I guess we’ll see.
Same for TKnarr’s points. Most web developers work by running their application server on localhost. So now I need SSL and certificates for that too? Come on.
Re: Re:
“certificates cost (a lot of) money”
Not really, depending on what you actually want or need. Basic SSLs can be bought for less than $10/year, and don’t run into 3 figure sums until you start adding a lot of subdomains or features. The cheap ones aren’t suitable for e-commerce, but if you’re doing that without HTTPS because you can’t afford a few hundred in basic overhead, you deserve to lose that business anyway.
“So now I need SSL and certificates for that too? Come on.”
I would hope a competent admin knows how to self cert their own server, and services exist to provide free SSL certs for testing purposes if you need something externally for some reason. These really aren’t excuses in 2015.
Re: Re: Re:
What about the sites that aren’t businesses? I have around 10 domains I run as basic informational resources, some as placeholders for my nieces and nephews when they come of age. They’re served as plaintext because that’s what they are, not web 2.0, no interaction, just read what you see. Are my domain costs now going to double because you decided that my publicly available photos need to be transmitted securely?
Re: Re: Re: Re:
“…Are my domain costs now going to double..”?
Uh, no?
1) Certificates can be had for free;
2) If you’re just ‘placeholding’ the domains but are not publishing, then don’t get certs;
3) If you’re just hanging on to the domains and don’t care about their Mozilla and Google ranking for now, then just don’t get certs;
and lastly but most importantly, just wait a few months…
4) Certificates will be available for free from EFF’s Let’s Encrypt project.
Press release:
https://www.eff.org/deeplinks/2014/11/certificate-authority-encrypt-entire-web
Let’s Encrypt:
https://letsencrypt.org/
Re: Re: Re: Re:
“What about the sites that aren’t businesses?”
Such people are far less likely to be hosting own their own servers. Many hosting providers provide shared SSL for free, and prices for dedicated certs are already being driven down significantly by the greater demand for certs and their increasing non-business usage. I have no doubt that competitive hosting packages will drive the prices down further, as they have made things like limited email addresses and paying premiums for more than 20Mb of disk space a thing of the past.
We’re not talking about forcing people to pay hundreds of dollars just to stay online. We’re talking about something that the market is already making steps to make as effortless and inexpensive as hosting itself.
“They’re served as plaintext because that’s what they are”
Cool. That doesn’t mean that communications are immune from man in the middle attacks and other things that SSL is designed to prevent, but it’s certainly less likely that you’ll be a target. But, should security be reduced for everyone just because you don’t think you’ll be a target?
“some as placeholders for my nieces and nephews when they come of age”
So you’re now arguing that the security of the web should be compromised for people who aren’t even using their domains? What’s wrong with domain parking, forwarding or other services that are available for free?
“Are my domain costs now going to double”
Depends on your hosting provider. Shop around. you have time, it’s not suddenly going to be mandatory tomorrow.
Re: Re: Re:2 Re:
I poked around and my host does provide SNI, which means I can config my sites to resolve over https with a big “THIS SITE IS LYING TO YOU” warning message. I’ll have to look into the free certs to get rid of that.
I don’t want to make anyone else’s communications less secure, but it still seems like using certified mail when I just want to send a “wish you were here” postcard. Postcards are still a thing, right?
Re: Re: Re:3 Re:
Yeah, some hosting providers still haven’t got the shared stuff completely right and/or are still geared toward trying to push businesses toward paying for full service. I have no doubt this will change in the time we’re talking about before general traffic becomes mandatory. Again, we’re not talking about something that needs to change instantly, and this particular market is very competitive and usually open to change. That’s why I’m not sharing in the concerns – by the time this becomes even remotely mandatory for smaller sites, it will be both as trivial as possible to implement, and providers will be competing on ease of use as well as price.
As for analogies, I can’t really think of a good one. The postcard one is a flawed since using certified mail involves extra time and effort on both sides, whereas if everything’s set up properly the person visiting your web site won’t have to do anything.
Re: Re: Re:3 Re:
Yes, but they’ve gone digital. We call them e-mail now, and they’re just as insecure. 🙂
Re: Re:
“certificates cost (a lot of) money”
In addition to what PaulT said, you can also self-sign your certs and have people using your site manually install your root cert to use your site.
This is unworkable for a publicly-facing site (who’s going to bother to install your special cert, even if they know how?) but can work quite well for sites that are not intended for the general public.
Also, if you’re talking about internal sites that aren’t going out to the internet at large, then you can ignore all of this HTTPS stuff if you wish without any problem (aside from the obvious security one).
Re: Re: Re:
The point being that an internal site might want to use the advanced browser features without having an SSL cert.
Too which I say too bad because my privacy is worth a slight uptick in your internal production costs.
Why should I use SSL on my personal, 5-page, statically-delivered blog? I can see why for a website with ‘users’, or perhaps for more interesting subject matters, security becomes an issue of import, but I just can’t see why the cost/benefit line should be set to zero.
Re: Re:
“Why should I use SSL on my personal, 5-page, statically-delivered blog? “
Counterpoint: why should insecure standards be retained because some blog owners who don’t have a lot of visitors or content don’t want to put in the work?
I understand that implementing SSL can be pain if you’re not used to it, but the web is also much bigger than your page, and the needs of the majority are what will always win out. Standards are deprecated all the time, and there’s rarely one that isn’t being used or preferred by someone. That’s just the way it is.
For the record, I also have a blog that’s not on SSL as yet, but I don’t expect inferior standards to be adhered to for my sake.
You have multiple options:
– Continue using HTTP, but risk losing visitors as secure standards are prioritised.
– Obtain a cheap (less than $10/year) or even free cert that gives basic SSL capability.
– Rather than host your own content, move your blog to a (usually free) service that provides SSL as part of their standard account package, freeing you from the need to admin the server.
Re: Re: Re:
This adds another cost and administrative overhead to be carried out by an individual who wants to put up a simple web-site. An unintended consequence of all such rules and regulation is that they tip the table towards corporations and away from individuals when it comes to all interactions with the general public. It may not be by much, but every little bit that a barrier to entry is raised, some individuals are put of from entry into an area or activity.
Re: Re: Re: Re:
You have the choice – administer your own server or use one of millions of other hosting options where the admin is done for you. These include local independent professionals if you’re scared of corporations. These include free options if you’re scared of the price.
If you choose to administer your own server, you’ve chosen the admin overhead, and the web is better off if you’re forced to obey basic security rules. As with everything security related, there’s a balance between ease of use and security, and I’m happy with the pendulum swinging back toward security. The web is full of compromised sites and servers run by people who wanted the freedom without the responsibility. Which is exactly why we’re having this discussion to begin with.
Re: Re: Re:2 Re:
I certainly agree with everything you said here. However: there are more important things — at the moment — than https.
For example (1) having functional role addresses and paying attention to them is one of the best security tactics available. After all, if the entire rest of the Internet is willing to provide you with free consulting, why would you turn it down?
For example (2) following BCP 38.
For example (3) setting up your web server on as secure an OS as possible with as minimal a software footprint as possible with as feature-poor a web server as possible.
Those things are easier to do and don’t require understanding of https/certificates/etc. that. I’m not saying that they’re the whole list — of course they’re not. And I’m not saying that https shouldn’t be on the list: for a lot of sites, it should. But i think it’s important to start with fundamentals and work up to more sophisticated measures.
Re: Re: Re:3 Re:
“having functional role addresses and paying attention to them”
I used to work tech support for a hosting company, and I can tell you that a depressingly large number of people fail miserably at the latter point. If it’s not a focus of their job role, most people tend to ignore things if they’re running properly.
“getting up your web server on as secure an OS as possible with as minimal a software footprint as possible with as feature-poor a web server as possible.”
If someone is too lazy/stupid to learn how to set up an SSL certificate, they’re certainly not competent to do that effectively. Why is it not a good thing to weed out those people before they have a functioning site accessible by everyone?
Re: Re: Re: Re:
Exactly.
And to go to PaulT’s point “…if you’re doing that withut HTTPS because you can’t afford a few hundred in basic overhead, you deserve to lose that business anyway” — a few hundred might as well be tens of thousands to some. One of the great things about the internet is that it lowers the entry cost for many businesses to near zero, allowing individuals to start up with sweat equity and compete with the big boys. I know, you have to pay for hosting, buy a computer, etc. — which is kinda the point. Any individual expense might be relatively small, but they add up.
And what about people (or non-profits) who don’t want to make any money off their website, labors of love and/or art and/or social change? Those sites are as important as (maybe sometimes more important than) money-making sites.
Re: Re: Breaking what isn't broken.
Re: Re: Re: Breaking what isn't broken.
“There is no value to imposing a “Brazil” style beaurocracy on everyone.”
Other than the fact that it can take a little more admin at present, how is imposing HTTPS any more a Brazil-style bureaucracy than making everyone adhere to the other existing standards upon which the web is built? Standards are deprecated, protocols no longer supports, version upgrades forced, etc. all the time. What makes this one different, other than the fact that some people might have to do a little work rather than depend on a version upgrade of some software or other?
“BS for it’s own sake should not be encouraged.”
Agreed. However, the push for secure connectivity is nothing of the sort. Unless someone has a real counterargument that doesn’t boil down to “I don’t want to do the work”, “I’m assuming I’ll be safe because nobody reads my blog” or “it was expensive when I checked the price in 2005”, I fail to see the actual problem.
Re: Re:
Why should everyone’s privacy have to suffer because of your blog? Encryption everywhere or nowhere, you’re only as strong as your weakest link.
Any plans for Techdirt to support encryption fully?
Re: “We’ve been pretty vocal about supporting the encryption of more and more web traffic”
But: “Your connection to http://www.techdirt.com is encrypted with modern cryptography. However this page includes other resources which are not secure.” – warning from latest Google Chrome on fully-patched Windows 7, via LAN in UK.
Seems to be due to using http: for Google Analytics, LinkedIn sharing, and a handful of other plugins.
Re: Any plans for Techdirt to support encryption fully?
So… how does that negate the original point? If the 3rd party services they’re using are the only things stopping the site from being 100% HTTPS, why is this not a compatible position with a call for more services to support HTTPS?
no
don;t want any american certificates …free or otherwise.
Your gov’t can’t be trusted
Re: no
The US government is not the entity who issues these certs, so I don’t see how trusting it comes into play here.
Re: Re: no
The US government is not the entity who issues these certs, so I don’t see how trusting it comes into play here.
The US government doesn’t make Cisco hardware or encryption standards either, but they’re responsible for borking those up. It seems entirely plausible that the NSA has compromised major certificate authorities in some way, and if they haven’t yet I’m sure they’re working on it.
sidebar: Most VoIP is unencrypted
Although lot of VoIP carriers support encrypted handshaking and authentication, I’m not sure how widely it’s implemented.
However, most carriers use unencrypted RTP to carry the content of the call.
Internal web sites?
So I’m going to have to use ssl for a web site that will never be seen outside of a corporate firewall? Even setting up internal self-signing is a non-trivial cost for IT departments. All simply to use the nicer features of a browser? Not sure I’m entirely on board with this if it can’t be “disabled” with a setting.
Re: Internal web sites?
“Even setting up internal self-signing is a non-trivial cost for IT departments.”
A half-hour’s work is an overly burdensome cost?
Re: Re: Internal web sites?
Certs expire requiring re work regularly. Also in a self-signing scenario you have to create and manage your CA server infrastructure.
Re: Re: Re: Internal web sites?
And they take all of 5 seconds to generate and replace if you know what you are doing.
Re: Re: Re:2 Internal web sites?
Oh and they last for a year at a time before they expire.
Re: Re: Re:3 Internal web sites?
When you create your own cert, you get to specify how long they last. I usually make mine last for 10 years.
Re: Re: Re:2 Internal web sites?
Then I can hire you on the cheap to come in and do that for 300+ servers, each with around a dozen separate domain-headered web sites? (M&A are a bitch)
Re: Re: Re:3 Internal web sites?
Two words: Script and schedule.
Re: Re: Re:3 Internal web sites?
What’s the pay rate? Can I telecommute? Would I have the power to do any reasonable infrastructure changes so that I could just write a Perl script to do my job for me?
Re: Re: Re:3 Internal web sites?
You can afford over 300 servers, each with around a dozen seperate domain headered websites, and the bandwidth for all of that? Meaning either your a major media conglomerate or a hosting company? I mean what kind of business runs 3600 websites? Either you can afford to up your security, or you should be charging your customers if they plan to up their security.
Re: Re: Re:4 Internal web sites?
MOreover, i just realized, your talking about 3600 INTERNAL websites? all withb advanced HTML features? Who are you paying to make all these websites?
Re: Re: Re:2 Internal web sites?
And if you are a reasonably competent IT guy who has never done it before, it might take you about 15 minutes.
Because SSL costs more money and in practice is in the control of the root authorities, this sounds like a net neutrality issue. How is a browser putting a flag on unsecure pages forcing everyone to pay more for SSL to be “approved” any different than Comcast demanding more money from Netflix and steering customers toward their approved service. Sounds like lots of innovation stifling. Cue safety and security rebuttal. Cue sacrificing freedom for security counter-rebuttal.
Re: Re:
The “SSL cost more” argument died a long time ago. There are free certs available for relatively little effort, and the overhead of SSL is very low compared to the cost of doing almost anything dynamic on a site. The only real costs are in management of the certs and dealing with third parties like advertisers that won’t work with SSL sites.
And if you can’t see the difference between Verizon purposefully allowing their connections to Level 3 to degrade with the intent to force Netflix to move off Level 3 to a direct connection to Verizon for Verizon customer (with corresponding payments to Verizon), and Mozilla stating that implementing one technical feature should depend on another technical feature to help ensure the security of the first feature, then I don’t know what I could say to change your mind.
Re: Re:
“Sounds like lots of innovation stifling.”
Well, yeah, if you ignore the free options available, incorrectly define net neutrality and add a bit of paranoia then you can come to all sorts of crazy conclusions!
Re: Re:
The cost USED to be a problem for two reasons. 1. Was the cost of the certs. 2. Was that they required a dedicated IP for each domain and cert. As many have said, that is changing free options are available. Multi-domain certs are also available now and SNI removes the requirement of an unique IP address.
In short, yes, deploying HTTPS at that scale is expensive, but the benefit to users is tremendous and worth it.
How are the benefits of encrypting Netflix streams “tremendous and worth it”? Sounds like a faith-based claim to me. Care to share your scientific cost-benefit analysis?
Re: Re:
Given that all he did was restate Netflix’s opinion, listing they believed the privacy benefits outweighed the cost, it would be Netflix’s proprietary, internal, cost-benefit analysis that you want. Not Mike’s.
Re: Re:
How are the benefits of encrypting Netflix streams “tremendous and worth it”? Sounds like a faith-based claim to me. Care to share your scientific cost-benefit analysis?
Maybe you are asking the wrong entity that question. It’s obvious that Netflix has done a cost benefit analysis and feels the cost is worth the ROI as stated by Mark Watson of Netflix himself:
Re: Re:
How are the benefits of encrypting Netflix streams “tremendous and worth it”? Sounds like a faith-based claim to me. Care to share your scientific cost-benefit analysis?
https://people.freebsd.org/~rrs/asiabsd_2015_tls.pdf
Re: Re: Re:
How are the benefits of encrypting Netflix streams “tremendous and worth it”? Sounds like a faith-based claim to me. Care to share your scientific cost-benefit analysis?
https://people.freebsd.org/~rrs/asiabsd_2015_tls.pdf
That paper isn’t about privacy. Try again?
And why are we letting Google and Mozilla social-engineer the web? Even if I agree with the specifics of this or that, I oppose it on principal.
I certainly hope they turn this “feature” off for localhost. I’m all for making the web more secure and don’t mind setting up SSL for public facing sites, but having to set up certs and deal with the complications of SSL just to develop is overkill if all you want to do is play around with a new development tool or test a new framework and have no intention of creating a working site.
I still think HTTPS sucks as far as secure encryption goes. However, right now there are still strong influential voices that argue even against HTTPS, and say they NEED plain-text HTTP for various technological stuff.
However, once 99% of the web is encrypted it will be much easier to actually change the infrastructure of the Internet and make it encrypted by default, at a much lower-level (such as at the Transport or IP level). Asking for that now would be probably be impossible.
What about privacy? Will I have to supply my name, address, and other personally identifying information to a CA in order to obtain an SSL certificate? I can understand the desire for encrypted communications, but I’m also concerned by potential obstacles to free expression due to the need to obtain an SSL certificate before being allowed on the web.
Besides, SSL is not as secure as people think. Spy organizations like the NSA likely have keys for the most significant HTTPS websites (popular search engines, webmail providers, social networks, etc.), while workplaces have SSL-hijacking firewalls like Palo Alto. This means SSL will only protect against random man-in-the-middle attacks (which are rare) and ISPs (admittedly an effective measure against deep packet inspection).
Re: Re:
Here’s the thing. That personal information is in the cert so that strangers who you are going to ask to trust your site with their sensitive information (like their credit card number) will know who it is that is asking them to trust it. So if you are running an e-commerce site you probably want to put factual information into that that people can verify. If you are just trying to facilitate an encrypted connection for your own personal use, then just make crap up for it when you generate the cert if you are worried about that. There is nothing that says you can’t.
Re: Re: Re:
A self-signed SSL certificate is pretty much useless in the real world (and browsers might not accept them in any case), so that’s not a realistic option. Providing false information when dealing with a trusted CA is also not an option.
Also, the opposite of an “e-commerce site” is not a website “for your own personal use” as implied in your post. Websites can be legitimately both public and anonymous. If I need to provide my personal info to obtain an SSL certificate, the need for such a certificate becomes a problem.
Re: Re: Re: Re:
I realize now that it looks like I was implying that you put false information in the cert which I didn’t really mean to when I said “make crap up.” Which of course you could do with a self-signed cert. What I would do for something that is external but where you wanted a layer of privacy is create a small corporate entity and use the company information in the cert instead of your personal information. How is is that for a suggestion?
Re: Re: Re:2 Re:
Create a small corporate entity just to put up a website?
Re: Re: Re:3 Re:
I have no idea exactly what you are trying to do and on what scale or what level of anonymity you want to maintain. But you could just create a holding company like a LLC or a S-corp or something. You could even use a DBA but that is a little easier to track back to who it actually is.
Re: Re: Re: Re:
And browsers don’t generally reject self-signed certs automatically either. Usually they give you a warning with the option to reject it or proceed.
Re: Re: Re: Re:
Last cheap webhost I dealt with gave me an SSL cert without any identifying info. They got the cert. Not me.
Re: Re: Re:2 Re:
Yeah, but those usually are just domain validated and the level of encryption is not very high so you don’t really want to use those for anything other than very basic stuff.
Re: Re: Re:3 Re:
Re: Re: Re:4 Re:
I know the difference between the key and the cert and what each are used for. Most of those I’ve seen that were free were not only just domain validated certs but also 128bit keys since provider generates both from the csr.
Re: Re: Re: Re:
Also I intended to use running an e-commerce website as merely one example (probably the most common example) of the reason people would want an SSL certificate with identifying information in it. I by no means meant to imply that it was the only reason and everything else was to be considered a “personal site” where you could use a self-signed cert. I was merely stating that IF you were running a personal site where a self-signed certificate was adequate to just to facilitate an encrypted connection for yourself, the accuracy of that information really wouldn’t matter.
HTTPS everywhere is fine but...
A bigger issue (and more important actually) that is MUCH harder to tackle is would be forcing SSL on SMTP.
Moby's Dictum
A simple yardstick:
If the CIAFBINSA does NOT raise the roof with their tantrums decrying HTTPS to be the End of the World and the inevitable cause of the Deaths of a Million Babies a Day, then we can be absolutely certain HTTPS has been fully compromised and is an open book to the USG and its minions.
—
Re: Moby's Dictum
I suppose that the reason they aren’t screaming about that is that:
1. They can just pressure the hosting company to give them the logs when they want something.
2. They know that it will take a lot to get compliance from servers everywhere.
Re: Re: Moby's Dictum
They can just pressure the hosting company to give them the logs when they want something.
That assumes the host keeps logs of the contents of the https traffic, which seems unlikely to be a reliable assumption. Or maybe CIAFBINSA is satisfied with metadata, like what IP connected to the server when? Also doesn’t seem quite right, I think they want access to EVERYTHING.
They know that it will take a lot to get compliance from servers everywhere.
Everywhere, yes, but any reduction in their ability to snoop is cause for dire alarm from their perspective.
I can’t help but notice the irony of the writers on this site touting HTTPS as the saviour on the one hand and techdirt using an unencrypted google proxy for their RSS feed on the other.
Mindless over-reaction
This rush to https, as demonstrated by this website and many other places, reminds me of the mindless over-reaction to the possibility of terrorism after 9/11. Most of the over-reaction to 9/11 was by right-wing types and most of the “encrypt everything” over-reaction to Snowden is by left-wing/libertarian types. I wish everybody would just calm down.
Re: Mindless over-reaction
You’re right, widely implementing a common security standard is exactly the same as invading 2 countries and removing civil liberties. :rolls eyes:
What’s actually happening: for the first time in the web’s history, the security of non-e-commerce sites has actually been a real point of public discussion, and what’s on the table is something that a lot of people feel should have been implemented years ago. HTTPS was being implemented by large sites for other reasons long before the Snowden revelations (e.g. Facebook making HTTPS mandatory following the vulnerability exposed by Firesheep). It’s just that it wasn’t in the general public awareness before Snowden. Since there’s now more demand for security, more sites are implementing it, and it makes sense for it to become an overall standard.
Now, quit the scaremongering hyperbole yourself and deal with the facts, OK?
Re: Mindless over-reaction
This rush to https, as demonstrated by this website and many other places, reminds me of the mindless over-reaction to the possibility of terrorism after 9/11.
What’s interesting is that if it hadn’t been for the hysterical overreaction to 9/11, perhaps we wouldn’t have such a great need for encryption.
The Netflix encryption provides no benefit, it actually is harmful for the environment.
The moves are a know length and a know size provided a given connection speed. The ISP will always be able to tell what you are watching.
Further because video encoding does not produce a stream of bits at a constant rate the variation during the stream would quickly tell them what you started watching.
It is pointless.
Re: Re:
The moves are a know length and a know size provided a given connection speed. The ISP will always be able to tell what you are watching.
You’re claiming that each Netflix title has a unique length, and that ISPs know exactly how long each title is? How do they have this information, and how do you know that they do?
Re: Re: Re:
“You’re claiming that each Netflix title has a unique length, and that ISPs know exactly how long each title is? How do they have this information…“
Actually, the lengths of movies in hundredths of a second is very likely different for almost every movie, even if they are all, generally speaking, one and a half hours long.
If he is talking about the movie’s “exact” duration, from start to finish, I would think that this information would be readily available to anyone who is hosting those movies in file form and has software that can measure the exact length of each – something I would assume is available to anyone like Netflix who has to know such time lengths in order to do broadcast scheduling.
I would also assume that entities such as Netflix would also own software that could add or subtract a few hundred milliseconds to the length of any movie they were hosting, or speed up/slow down the movie’s running speed.
I think it was just mentioned here on Techdirt recently, that some Legacy Networks have considered speeding movies up in order to insert more commercials, so such time control is obvious possible.
While I doubt that Netflix does any of these things, I do not see any of it as being technically difficult to accomplish, or implement as an automatic process.
I am curious as to why you consider this sort of simple measurement and length comparison to be technically difficult.
Please note I am not agreeing with the poster that Netflix or anyone else does these things – just disagreeing with your apparent claim that many or most movies are the exact same length and that automated measurement comparison would be difficult to implement by entities such as Netflix.
—
1zqjfg'”(){}:/1zqjfg;9
1zqjfg'"(){}:/1zqjfg;9