Here’s to more HTTPS on the web
developers.googleblog.com
developers.googleblog.com
It seems to me that they are now walking a very fine line between improving the web, and taking over the web.
For many people Google IS the Internet - it's the provider of the search results they always see. Chrome badgers you to sign up for a Google account, and with it the associated services such as GMail.
9 out of 10 smartphones now run Android, and almost all of those are Google controlled (AOSP[1] is hardly a thing any lay-user knows about). Therefore for 90% of internet users, Google is their gateway.
If Google don't want to you know about something on the internet they have many routes to ensure you never find out about it.
If this was Microsoft doing this - the world would be in uproar, but apparently Google are allowed to get away with it? Where's the Antitrust lawsuits against Google? There's a one smoldering on in Germany[2], but it's getting almost no press - most probably because Google are suppressing any mention of it in their results or in Google News (Crazy? Maybe, but you can't disprove this either).
There are no web standards anymore - if Google want to add a feature to Chrome, they just go ahead and do it, forcing the other browser makers to adopt that feature lest they be left behind in the browser market.
Almost all big sites use some form of Google Analytics, along with advert providers such as DoubleClick[3] (also a Google company). You simply cannot do anything on the web without Google seeing in one way or another.
Put simply, the Internet is dead; All we have now is the Googlenet.
--
[1] https://source.android.com/
[2] http://www.ibtimes.com/android-antitrust-googles-big-problem...
I agree with a number of things in your post, but I don't think this is a likely explanation. A couple of months ago, a German newspaper published some data about their traffic sources[1], showing that 20% of their visitors came from Google. Some others released similar data (see the linked thread - note that it's mostly in German). I don't think that's anywhere near enough to effectively suppress these reports (though the whole echo chamber thing is a problem of its own), so I don't think it'd be worth it for them to even try and risk possible legal ramifications.
I think the more likely explanation is that just about no one cares, which is much more worrisome.
[1]: https://twitter.com/zeitonline/status/781779996473958401
I never felt harmed by Microsoft, using their products since MS-DOS 3.3.
That's why justice, thankfully, isn't based on your own personal feelings. If you read the sentence, it's pretty strong.
Do you want everybody to just not do anything until there is a standard? The modern web you have to start by having a working implementation for testing and refinement. Once that is done, you go for the standard. Mozilla also 'just implements' stuff and then tries to standardise it later.
> You simply cannot do anything on the web without Google seeing in one way or another.
without Google seeing SOMETHING, but that does not mean that SOMETHING is useful
Are they taking credit? I read this as more of a report on the state of HTTPS in 2016, not as Google taking credit for HTTPS adoption on the web.
Though to be fair, Google absolutely has done a lot to promote the adoption of HTTPS. They're a platinum sponsor of Let's Encrypt, they [made HTTPS a (small) positive ranking signal][1] back in 2014, and they're even using Chrome to push HTTPS adoption by [making the security problems with HTTP more visible to users][2].
[1]: https://webmasters.googleblog.com/2014/08/https-as-ranking-s...
[2]: https://security.googleblog.com/2016/09/moving-towards-more-...
> Therefore for 90% of internet users
There are a lot of cheap Android phones in the wild which are used primarily, or even exclusively, for voice and SMS. These devices count towards Android's overall market share, but they have very little effect on web usage.
Even beyond that, studies have consistently shown that iOS users use the web more than Android users:
http://www.businessinsider.com/android-is-beating-ios-in-web...
(Old study, but no reason to suspect the results have changed dramatically.)
Isn't that normal? First you add the feature to your browser, then if people start using it you think about standardizing it. The alternative is to spend a bunch of effort standardizing things nobody wants.
If anything, I'd like to see more standards that first require a concrete implementation. I think everyone's been handed a spec that has loads of problems when you actually try to implement it. Look at the 'export' keyword in C++.
This is how the standards process has always worked! Per RFC6410, a proposed standard can't advance to an "Internet Standard" until there are at least two independent working implementations.
The W3C has a bad habit of writing "standards" before any code has been written; sometimes even before it's clear that any code should be written. (EmotionML, for example.)
1) Send an intent to implement to a public mailing list, describing the thing you want to implement and its existing standardization state, if any.
2) Add the feature to your browser, enable it on your nightly/dev/canary/devedition/whatever channels but not release.
3) Get feedback from people trying out the feature on those channels. Explicitly solicit feedback via twitter, conversations at conferences, etc, etc.
4) Write a draft spec, run it by other browser implementors.
5) Send a public intent to ship, indicating what other browser vendors think of the idea, what web developers think of the idea, stability level of the spec, etc.
6) If the relevant people in your org (the API owners for Blink; for Mozilla it's a bit less clear so far) approve, you ship.
Step 6 can precede finalized standardization. But it can come after too; in particular the "two implementations" criterion for standardization can be fulfilled by pre-release implementations that are on track to become released.
Furthermore, "they can't keep other search engines off the internet; they're just what people use" could equally well be said about browsers in 1998. Microsoft never prevented anyone from downloading and installing Netscape.
The post seems to say that they're trying to get out of the way of https adoption. It doesn't even mention their initiatives such as requiring encryption for http2 or the location API.
> - most probably because Google are suppressing any mention of it in their results or in Google News
Is the world going completely mad[1]? This is so obviously wrong, simply because people don't google [news] to be informed, nor does Google News have enough influence to be meaningful. You think the WSJ/NYT/Daily Mail/SPIEGEL depend on google to find out the news? Then where would these news reports actually come from that google is supressing?
> There are no web standards anymore - if Google want to add a feature to Chrome[...]
Which isn't actually true, because Safari is large enough to require support. And because Google is a dependable participant at the WHATWG. It's also the only way that actually works, because you need an implementation for any specification. Looking at the pace of browser improvements and level of compatibility – if that's the result of Google's corruption, I want more of it.
> forcing the other browser makers to adopt that feature lest they be left behind
Or as they used to call it: competition. It's markedly different than MS's extend-and-extinguish strategy back in the days. I can't think of any features that disproportionally benefit Google.
> You simply cannot do anything on the web without Google seeing in one way or another.
There seems to be some sort of newfangled "adblocking software". I'm also not quite sure if google correlates analytics data with user profiles – I know they don't do it on my sites because I'm using their feature to anonymize the last 3 digits of IP addresses (as required by law in my country).
> Put simply, the Internet is dead; All we have now is the Googlenet.
As long as I can substitute "Google" with "Facebook" and make the sentence actually more believable I don't think we're quite there, yet.
Why don't browsers default to trying HTTPS if there is a DNS record but no response on port 80? Or better yet, default to just trying HTTPS first. I understand I can add my site to browser based HSTS lists, but this doesn't really help people developing command line applications or API client libraries where a 302 could be followed without the developer even noticing and if I want to develop a MITM proof application I currently have a usability problem.
Is there a reason to support HTTP at all, other than current user experience in the browser?
We'll also face some new challenges. Over the years, many users have learned to "look for the padlock" before entering their passwords. More sites moving to HTTPS will also increase the percentage of phishing/attack sites served over encrypted connections -- with the padlock to match. We'll need to renew our focus on training users to check for the correct domain name (and possibly an EV cert), or phishing sites with a cert from Let's Encrypt will become a real threat. Browsers are moving in the right direction, displaying https less conspicuously than before, and emphasizing connections with EV certs.
[1] http://httpwg.org/http-extensions/draft-ietf-httpbis-http2-e...
Other types of certificates (such as EV, which attempt to verify the business entity requesting the certificate exists and is indeed requesting it) already get different treatment in most browsers (namely the organization's name being shown in a green box).
I'm still amazed at the fact that FCC regulations confuse encryption with authentication. On ham radio frequencies, you usually can't transmit encrypted traffic, because that's not what the frequency allocation is for. But for certain types of remote command of automated craft, you're allowed to encrypt the message because someone sending a tampered/spoofed message could crash your craft. Which completely confuses encryption and authentication! And that's from people whose entire job is to think about rulemaking for electronic communication.
It's true that you can construct a signing scheme by using a decryption algorithm: treat the hash as if it were a ciphertext and "decrypt" it with the private key, then anyone can verify it by "encrypting" it with the public key. That way only the person with the private key can sign it, which is the direction you want. But this doesn't run afoul of the FCC's rules, because you're not obscuring the message; everyone has the public key.
If you're using so-called "textbook RSA" (i.e., the type of RSA you can explain on a whiteboard, with no hardening against real-world attacks), it's also true that the encryption and decryption operations are the same mathematical function. But you don't actually want to use textbook RSA, at the very least because of malleability (if you multiply two textbook-RSA ciphertexts, you get the same thing as if you'd decrypted them, multiplied the cleartexts, and encrypted that, except you don't need to know the private key), but also because of determinism, timing attacks, etc. Real-world RSA signature algorithms bear little resemblance to real-world RSA encryption or decryption algorithms.
One authentication scheme which doesn't involve any encryption is HMAC with a shared secret key. Sure, you need the key to authenticate the message -- but that's perfectly fine in many situations.
This is - unfortunately - bad advice. The padlock tells you that you're on the site that you are. But it doesn't tell you anything about the trustworthiness of the site.
If you're at https://evilhacker.com and you enter your password then evilhacker will get your password.
I'm still leaning towards the password manager side of the dilemma, but the situation isn't great on either.
[1] https://twitter.com/taviso/status/769378052254015488
[2] http://arstechnica.com/security/2014/11/citadel-attackers-ai...
LOL, how fucking naive people are. HTTPS is good, yes. But HTTPS is also being fostered by service providers (Googles, Facebooks and other PRISM supporters) to try decrease revenue from operators and network providers, making sure they stay as random data pipes.
Google is probably the first company out there helping the government and other parties gather all your data, filter it and serve it to whomever is the highest bidder or for whichever obscure political reason.
If Google and the like were so big on privacy they'd do more to ensure that users can directly and privately talk to each other without intermediaries.
It's naive to think it's any good against states or sophisticated attackers.
I'd like to see the default User-Agent header for HTTP2 be as short as "Chrome". Remove cookies, find ways to keep the identity of a user private.
On the other hand, trackers will probably just switch to detecting the capabilities of the browser using JS and then map each distinct set of capabilities to the matching browser version. In that scenario, an Add-On replacing your UA will actually increase trackability, as long as the majority of people aren't using it.
Also it would be very easy to detect if a user is running an adblocker then.
security.warn_submit_insecure
This setting was removed at some point (FF19, IIRC) and is currently (AFAICT) a NOP; cf. bug #799009, "Remove support for obsolete SSL-related warning prompts" [0]
No it isn't. HTTPS fights passive surveillance. The pervasive surveillance is already inside the HTTPS link, and deliberately so.
The actual best way we have to combat pervasive surveillance is to grow a spine and work to end the 1st and 3rd party surveillance our organizations implement, rather than just bitching about surveillance on the internet.
There are only a few actors positioned on the network that can passively perform surveillance pervasively (not just incidentally). My threat model extends beyond the NSA and ISPs. We've been taught to hate and fear them, but I'm sick of only thinking about the last crisis instead of focusing on the underlying problem.
Totally useless, studies show that user just don't look or care. This after all the effort put into this.
The solution is new authentication that takes into account the domain.
This is exactly what has been done in the new FIDO standards, UAF and U2F. If you use U2F as a second factor on google, dropbox or github phishing is already a problem of the past.
These standards have now been given to the w3c and they are working on a further standard based on the fido ones.
How does https stop NSA or any resourced state actor? Even ordinary run of mill organizations routinely mitm https.
And to add insult to injury this naive https protects against surveillance is promoted aggressively by people and entities who are known to be in bed with state entities, leading purveyors of spyware and are aggressively building profiles of individuals every second.
The public key infrastructure in modern browsers is also about to require that CAs use Certificate Transparency (a year from now), which is definitely an obstacle even for nation-state adversaries if they want to stay under the radar (once it's fully rolled out and backdating in order to bypass the requirement isn't possible anymore).
Finally, if you're the target of a nation-state adversary, there are probably things you'd have to worry about other than the Web PKI. It's unlikely to be the most effective way to own you. The Web PKI isn't the weakest link by far.
If a nation-state attacker decides they really want your secrets they will probably get them. This can mean measures up to and including clandestine hardware modifications of systems you use. HTTPS isn't going to save you in that case.
HTTPS can, however, take a lot of the sting out of pervasive information insecurity promoted by nation states. It forces nation state attackers to go from passive to active attacks if they want to tamper with your system or read the contents of your communications. Pinned keys can thwart MITM tampering, when pinning is available, and even when an active attack can compromise security it's more likely to leave traces. It forces a natural balance on intelligence agencies that are (sadly, apparently) un-constrained by the consent of the governed: use that great 0-day exploit to monitor everyone you slightly suspect and it will be discovered/fixed that much faster.
HTTPS doesn't do anything to prevent metadata based surveillance, of course. But keeping the contents of communications private still imposes significant and worthwhile limitations on how metadata surveillance is used for further targeting. Any broad security measures that make the NSA's adversarial role harder to perform also makes life harder for for attackers from other nation-states; I'd rather that everybody be able to keep the contents of their conversations secret than nobody be able to to, if we have to pick one extreme or the other.
That surely doesn't make the web any safer ;P
Blogger sort of worked fine until they hugged it with js and their latest super cool network and view engine. Let's see if they rewrite the whole blogger thing in webgl soon. I wouldn't be surprised.
Also I'm sick and tired if closing those cookie notifications.
PS. I browse the web with js enabled like the majority but there is no need to use js to render 50kb of text.
Expensive? How?
Thanks to Let's encrypt and others, certificates are now free.
Let's Encrypt is still far from being convenient and usable for small companies or individuals that don't want to manage infrastructures and administration like writing a cron job that refreshes your certificate.
The lack of raised hands, should answer for you why LetsEncrypt is not ready for mainstream use.
Until Cert renewal is baked into all the hosting apps/platforms - HTTPs will never be ubiquitous.
Not that they host it with their own computers, but they rent some space online and host it there.
EDIT: Replied to the wrong parent, please ignore in this context.
EDIT: You can't delete comments with replies anymore. It's very annoying.
I also host with WPEngine, a more progressive WordPress only host - which has made SSL implementation extremely simple. They're an example of a modern approach to web hosting.
It's the low cost, shared (LAMP) hosting providers that need to implement it into their sales process and make switching existing non-encrypted sites smooth. Unfortunately, I don't see them moving to "free SSL for everyone!" anytime soon as it's a revenue generator for most.
(it's not exclusive to just laravel apps)
A MITM attacker could intercept my initial request and then proxy everything afterwards. So he would get all the data in clear text.
Somebody could probably put an app onto a phone that offers a wifi hotspot and then MITMs everything. By walking around with that phone he would probably capture all kinds of "private" communication all the time. And none of us would know.
When I am in an airport and see a hotspot "Free Airport Wifi" I always suspect it is such an app in reality. I mean, everybody can call their hotspot "Free Airport Wifi".
(Ironically, IE used to ship with exactly that warning years ago, but they were way too much ahead of their time)
[1]: https://security.googleblog.com/2016/09/moving-towards-more-...
Man, people really don't think these things through, do they?
The end result of making that enabled by default would be that sites start using plaintext for their password fields. Try detecting <input name='password'> and sites start changing it to <input name='p4ssw0rd'> to get around it. Throw warnings on any POST submission and watch sites start using GET for passwords.
You can't force people into good practices. You need to make the HTTPS portion so easy that they have to go out of their way to undermine security. Let's Encrypt was a good first start. Now we need at least one competitor to them for free certificates to push innovation forward. And we need Apache and nginx to auto-negotiate TLS certificates and OCSP stapling with zero configuration changes. The default config should opt-in to this, and you'll have to manually disable it. Caddy was a good step there, but nobody uses Caddy. They use Apache, nginx, or IIS.
You'll also be going against specs, HTTP should go to port 80( which typically isn't secure.), a browser unilaterally deciding to go against a legitimate user wish is bad form.
Besides, now that most sites run on https, making the http-only ones slower would be a good thing.
When it comes to security, TLS is crucial to the security infrastructure of the internet as a whole; however most of the current security problems on the internet don't actually involve TLS vulnerabilities, even though those tend to make a lot of news in the technology press.
The bar for exploiting TLS vulnerabilities generally requires setting up a legitimate seeming entity and injecting yourself into the internet traffic routing infrastructure, it is very much possibly (and indeed easy for state actors) but it is a much higher bar for common cyber criminals.
Currently site owners are not allowed to default into https on first visit. Trying both will give them this choice.
Any site lacking HTTPS should instantly close connection attempts on port 443. But some it seems choose not to respond at all, making the browser unsure if the site is just slow or if an HTTPS service doesn't exist.
[1]: https://github.com/EFForg/https-everywhere/tree/master/src/c...
What if it's their bank and they really need to pay a bill right now? Maybe the HTTPS site is just broken right now.
Users aren't wrong for clicking yes through these dialogs. This kind of UX is setting them up for failure with impossible choices. Its even worse in practice: users (including programmers, as evidenced by the comments in every HN thread about HTTPS) won't understand everything that's in play before making this decision. Assume users always click yes.
HSTS, preloading and restricting new features to HTTPS etc. are ultimately working to deprecate non-HTTP (inside browsers).
> "Maybe the HTTPS site is just broken right now."
In the case of a bank, it's extremely unlikely that they are falling back to HTTP. It's much more likely that sslstrip is in place if you had this. The cost and hassle of someone having access to your whole bank account, is likely much higher than the fines for a late payment.
* Pages can send the Strict-Transport-Security header to tell the client that future visits to them should be HTTPS-only
* Pages that send that header can also ask to be included in a list that ships with the browser to handle the first-time visitor case: https://hstspreload.appspot.com/
It is really difficult for the average user to clear HSTS/HPKP data. You can't just clear your history, you have to go to about:permissions or chrome://net-internals#hsts to do that.
Maybe that's the experience you want. But I think it'd be a tough sell to any business to have their users presented with a certificate error message for up to four days because Globalsign screwed up.
Public key pinning is even more dangerous. Not the least of which because there are no longer two free providers of SSL certificates for your backup cert.
This is yet another problem that could be solved with DNS signing -- both the risks of HSTS and HPKP would be gone. The domain could have a new TXT record of "TLS=Always" that you could flip on or off as needed. The TTL on that could be 3600 seconds instead of 4+ days for a bad OCSP response, or the suggested (by SSL Labs) 6+ months for an HSTS response.
Are you making the argument that a business would want the ability to turn off HTTPS enforcement temporarily in case something like the GlobalSign thing happens? Because I think that's a terrible idea. They should just switch to a different CA, or get the CA to sign a certificate that's not impacted by that issue (which I believe GlobalSign offered). Even excluding Let's Encrypt, the price tag for that is < $10 and it's done in a matter of minutes (and only getting better with ACME). Since we're talking about businesses here, better yet: Have a backup certificate from a different CA ready. This is really no different than all the other things you'll need to do to run a reliable service (like have more than one web server). It's not like one CA screwing up means your domain is dead until they've resolved the issue. Same thing goes for HPKP, since a backup pin is required.
Your argument is also not specific to HSTS/HPKP - you're basically saying that HTTPS in general is dangerous for a business because of this. If your site offers HTTPS without HSTS and without redirecting to HTTPS by default, you'd still have users who bookmark HTTPS links, or search engines indexing those links and all of those would also fail, with no way for you to fix it other than switching CAs.
> This is yet another problem that could be solved with DNS signing -- both the risks of HSTS and HPKP would be gone.
I don't want to get into yet another DNSSEC discussion (that's what we have @tptacek for, anyway), but I don't see a huge difference here. Switching CAs can be done in less time than the TTL you're suggesting. Practically speaking, if you want to factor in "time to find a new CA" or something like that, I'd argue that most people won't run their own DNSSEC infrastructure and rather use something like Cloudflare, so the same "time to find a new <foo>" principle would apply here if they've messed up in a way that takes a long time to resolve.
That's only true for somewhat carelessly configured HPKP.
With HSTS you can use any valid certificate. So all you need is obtain a certificate from another vendor. With Let's Encrypt, this will take you fifteen minutes tops.
A careful administrator deploying HPKP would probably pin a key they have securely stored somewhere and, should a disaster strike, go out and buy a certificate for that pinned key. Again, that would take an hour at a cost probably lower than his lunch.
As others have mentioned, the current best defence against this is HSTS (and, in particular, HSTS preloading). I think the best explanation of it is here: https://www.chromium.org/hsts/
At first I thought the fact that the percentage is higher is because by default they contact more google services (presumably all over https) than other os/browsers. If this hypothesis is correct, does it mean that the holes are periods where some of these services were failing to provide https?