Hacker News Reader

> a random decision by Google

What do you think is a random decision?

> However i think that sites should make decisions on their configuration

It's OK when they have ideas what they are doing, but that's not always the case.

Before my trip to Kaua'i I googled some dive shops on the island to book a scuba diving trip. Every dive shops on the island seems to be using the same vendor to process online order of the reservation, which has the same form to input credit card number, and has some text around it saying "it's secure". They are not secure. They are on HTTP: https://twitter.com/fishywang/status/895133987525476354

Wow. Unless this was some accidental configuration issue, this is inexcusable.

Those forms sit in an IFRAME and content is loaded via https. Example from http://seasportdivers.com/ :

That's not sufficient when the external page can be controlled and the iframe target set by it.

Agreed that in situation like this it's near impossible to ascertain that iframe target wasn't altered, unless you already somehow know what it was before you got mitmd.

Yeah, that’s a little better but can’t an attacker inject something in the surrounding the age that compromises the iframe? Or even rewrite the iframe to use a proxy under the attackers control?

Maybe the vendor improved since then (it's still not very secure as others and Chrome pointed out), but I remembered that back last Aug I searched for "https" in the source code and that's not the case.

Even now it doesn't inspire much confidence :)

This is possible because how ubiquitous the idea of HTTPS-all-the-things is now, not the other way around. Further, HTTP IS insecure(the S literally means secure) so...

I feel the push to HTTPS is bike shedding. It solves a problem, but it's not a big problem.

Most people don't need HTTPS for most sites. I think it's safe to say most security and privacy breaches are due to poor practices on the back end or by end users.

The ability for third parties to sniff your traffic is a big problem.

It's not a big problem if the traffic is inconsequential.

If I'm passively browsing I don't really care too much. If I'm submitting forms, or working in a authenticated session, that's a different matter of course.

And as easy as it is to get a certificate these days, what does it really prove? It stops 3rd party snooping, but then again so does a self-signed certificate.

I think you're confusing authentication vs encryption. If you were MITMing someone and using a self signed cert for example.com that connection can be encrypted (if the user clicks through the warnings) but says nothing about your trust for the site.

Let's Encrypt, or any other low-cost SSL certificate, says very little about my trust for the site either. It's just too easy to get them to think they really mean anything.

An expensive DV certificate doesn't really say any more than a cheap one, except that the person buying it had money to burn.

Whether an EV certificate should do much more for trust than DV is a matter of some debate.

All new certificates for DNS names in the Web PKI today (and for some time now) must result from the CA having used one of the Ten Blessed Methods to validate the Applicants control over the name, regardless of who paid how much.

Let's Encrypt offered three of the Ten, but one was discovered to be flawed due to the way some major bulk hosting services are configured, so that leaves two (of Nine, since in practice any implementation of the Tenth Blessed Method is flawed the same way).

Even flawed Blessed Methods are far superior to the checking (basically none) we can reasonably expect from a normal person using a web browser. But still, improvements upon the Blessed Methods are a topic of public discussion, if you think you genuinely have a better way you should definitely let the CA/B Forum or m.d.s.policy know about it.

Having any valid cert (DV or otherwise) proves that you are viewing the example.com that the owner of example.com wants you to see. Without a certificate, you can/will be MITMed.

>It's just too easy to get them to think they really mean anything.

I'm not sure what you mean by this:

1. Are you saying that there is a vulnerability where you can get a valid certificate for a domain you don't own?

2. Do you mean the fact that valid owners of a domain can get a certificate easily?

If 1, please provide more info. If 2, why is that a bad thing?

The traffic is only inconsequential until it's not. It's a privacy matter, not strictly a security matter.

That's simply not true. 99% of the time I could care less if a middle man sniffs my traffic. HTTPS is for that other 1% of the time.

The hypocrisy here is amazing, too, because while pushing HTTPS, Google itself is actively following everybody around, tracking everything they do online.

Blackmail, economic exploitation, political repercussions including imprisonment are all real consequences of surveillence.

I'd like to see something comparing the number of people blackmailed or exploited by sniffed HTTP traffic versus the number of people affected by back end exploits or social engineering. Everybody screams about HTTPS because it's easy to do, but it's a tiny problem in the grand scheme of things, and it gives people a misplaced sense of security.

To be fair, there's not much that browser makers can do about back end exploits and social engineering. Google aren't in the business of writing back ends for third parties, and it's difficult to know if a website's back end is insecure, so I don't know who you expect to hear "scream", or who they would scream about.

The article is about one practical measure that a browser maker has taken to improve the piece of user-facing software that they are responsible for, and some users of that software are applauding this improvement.

Having said that, I do accept your over all point that there is a lot of other work that still needs to be done in securing the web. As you suggest, that's not going to be easy, but let's not fail to fix the things that we can fix already.

https is about two big things in my mind.

The obvious one is that it makes your traffic hard or impossible to sniff.

What's often overlooked is that it also makes your session highly resistant to tampering by 3rd parties. These parties include:

1. Anybody who might have access to your home WIFI network.

2. Your Internet Service Provider. There's been plenty of documented cases where ISPs have injected 'harmless' HTML.

3. Any number of bad actors if you're using any kind of public WIFI.

4. National actors. That's the NSA in the United States, where we have clear evidence that they have been capable of intercepting unsecured connections and injecting unreleased attacks into targeted computers.

This is not tinfoil hat stuff.

The benefit of https is undeniably greater than the cost.

I'm not crazy about how Google throws their weight around in a lot of cases either. But in this case, I think they're doing the right thing.

1 and 3 are due to poor end user security and won't be solved by HTTPS, and 2 and 4 are lost causes and also not solved by HTTPS.

An ISP is by definition a man in the middle, and unless the user checks certificates for every page and resource they fetch then the ISP can inject their own certs and monitor traffic if they really want to.

And most of the time national actors like the NSA will have better ways of getting the information if they need it

An ISP cannot inject their own certificate. That is decided by your OS or browser vendor.

An ISP could inject their own certs very easily. Send an email to customers -- here run our "tune up" app to speed up your computer. A huge portion of customers would probably do it. Bingo, new CA roots installed.

In that case the ISP would be inducing the user to install malware. If the ISP is willing to do that, then you should probably view them as malevolent adversaries in your security model. I don't really think that an OS can protect against this in any reasonable way if that OS allows users to update certificate stores themselves. I don't really view this as a problem with the certificate model as opposed to plain old social engineering.

In any case, I don't think "an ISP could inject their own certs very easily" is a fair characterization unless you put it on the same footing as "anyone with your email can get people to install malware easily".

What's rather more difficult is doing that without it being noticed.

As a concrete example, Lenovo were caught.

> https is about two big things in my mind.

Three things not two. Confidentiality, Integrity, and Authentication.

The real reason for Google pushing this is is due to ISPs having genius idea of start replacing ads on sites with their own.

Google is not doing this without interest, but I guess it overall is beneficial for us as well...

It is a huge problem

I agree. Nobody is attacked using MITM, which is the only thing HTTPS prevents. Most credential leaks are due to insufficient security at the server, not the connection.

> Nobody is attacked using MITM, which is the only thing HTTPS prevents

The only thing?

I can think of four others off hand. That said, the “only” thing is pretty important in itself.

It's not important at all for most people. How many times have you been MITM'd? I'll tell you about me: zero. Nobody cares enough about me to do that.

You know what people get bitten by? Hacked servers where the whole website is under a phisher's control or malicious website which downloads malware to your machine or sells your data (eg, Google, Facebook).

Maybe my knowledge is lacking, so please tell me what those 4 things are that you're being so elusive about. I suspect they are also as unlikely as MITM.

I've been MITM'd numerous time in the past. I've been MITM by corporate netorks filtering my traffic. I've been MITM'd by scummy and public wifi hotspots trying to inject ads. My own domain provider once MITM'd my domain in a weird attempt to tell me my domain was expiring...

I'm not trying to protect myself from a targeted attack. I'm trying to protect myself from the enormous amount of scummy behavior in this whole industry. When I connect to my bank, I want my data to be secure not only against malicious activity, but negligence and incompetence. This is the threat model that HTTPS-Everywhere protects against.

Sure, people get bitten by viruses and phishes. But let's fix things one step at a time.

> When I connect to my bank, I want my data to be secure not only against malicious activity, but negligence and incompetence.

What bank do you use that doesn't use https already? Maybe it's time to change your bank rather than force every website in the world to switch to https.

Of course my office pushes a root certificate to all the devices and Skype for Business breaks unless you’ve trusted that certificate to handle SSL traffic.

> It's not important at all for most people. How many times have you been MITM'd? I'll tell you about me: zero.

How do you know? What is your groundless, evidence-free assertion worth to you?

> Nobody cares enough about me to do that.

I have detected Firesheeping on coffee shop networks in the past. Guess somebody cared about all the people in there, huh?

The conflation of Google using information collected about you in aggregate to provide advertising services and man-in-the-middle attacks on clients is dishonest, disingenuous, and at this point downright malicious. Stop.

I’ve been MITM’d before.

Usually shitty public WiFi providers injecting ads.

So the whole RFC Comcast submitted containing details of how they MITM HTTP traffic...

https://tools.ietf.org/html/rfc6108

Nobody is affected by this?

Isn't that putting the cart before the horse?

If the connection were HTTPS they could simply block it or redirect it wherever they want to give the same message. An ISP will always be able to MITM the connection.

You can't redirect HTTPS traffic unless you have a root certificate or have the private key of the site, and blocking HTTPS traffic would make at least 68% of web traffic not work, so not a real option.

Can't an ISP's DNS server tell you that https://www.google.com is at 10.10.10.10? And that is an internal server hosting whatever ISP wants.

They can, but you will get a certificate error, because the ISP doesn't has a valid certificate for the domain.

Exactly. It will show up in any modern browser with a big red "This site is not safe!" type of message if that was to happen. This is one of the reasons Google (and others) so proactively protect the certificate infrastructure so meticulously, and run efforts like https://www.certificate-transparency.org/

Yes, and that is an argument for https with certificates...

Man in the middle attacks are more common than you'd think. Many corporate networks inspect outbound network traffic. I've heard of some coffee shop WiFi spots that also modify traffic to inject ads. Having someone tamper with your traffic, is a big deal. Especially consider many websites people visit are sensitive in nature, e.g. Google almost certainty knows more about me than any other human being -- they might even know more about me than I know about myself.

Most corporate networks are going to inspect or block HTTPS traffic too. They have security and regulatory compliance concerns, and consequently deploying tools capable of intercepting that traffic is pretty much the norm these days. It's all but certain that if you have a work PC then your contract/handbook/etc. states that this may happen, unless you're in an area where the legal basis for this sort of inspection is weaker.

Protecting people who aren't at work but are using a potentially hostile network (public WiFi, etc.) from their own device is certainly a legitimate concern.

Of course, this is a feature in certain contexts: I’d love to be able to inspect all the traffic going in and out of my home network and possibly even modifying it at the edge device.

Try fiddler.

I've inspected my own HTTPS traffic a number of times using it including e.g. traffic from e.g. iPads where my Desktop was effectively acting as "the edge device". Of course, this is more for debugging than aggregate statistics/monitoring...

This won't let you inspect traffic secured via certificate pinning without additional reverse engineering to figure out how to replace the pinned cert, but it'll work fine for vanilla HTTPS / generic CA based stuff (e.g. all browser traffic.)

> This won't let you inspect traffic secured via certificate pinning without additional reverse engineering to figure out how to replace the pinned cert

Replacing a cert doesn't get around cert pinning. That is the exact use case that cert pinning protects against.

They meant replacing the cert fingerprint in the app that’s using cert pinning.

That makes sense. Thank you.

Couldn’t a mitm proxy just strip out the relevant headers?

It appears you're talking about pinning in browsers only, so I'll address from that perspective only.

For public certs: Yes, but that would only produce the desired effect if the site hadn't yet been pinned, and this was a first connection, or in the case of the pins having expired. In other words, the pinning can only be stripped out if there is no pinning already in place on the client.

However, this will soon be a moot point, as Chrome removes pinning in favor of cert transparency. This will reopen this security hole in browsers simply trying to be secure within captive portals and other insecure networks. Tor has pinning that would extend from inside the portal to outside, so that may be one option, but I don't yet know how sturdy that is.

Firefox at least will disable pinning if it sees a certificate signed by a user-supplied CA, on the one hand to facilitate this kind of debugging and on the other because otherwise enterprises using MITM boxes wouldn't be able to use Firefox. I suspect Chrome does too.

Yes, all major browsers do that.

> It solves a problem, but it's not a big problem

Exactly. In the overall threat landscape that computer users face using HTTPS for cat videos and blog posts is meaningless.

Everyone who needs HTTPS already implemented it and any individual user who actually cares about security can use a VPN.

Are you proposing that Chrome drop the security warning if it detects that the user is visiting a site that only has cat videos or blog posts on? Do you realise that people have been arrested for writing blog posts?

Not only for writing, but also for sharing/reposting/liking/upvoting.

You may be lacking SPF, DKIM or DMARC records. The lack of these records is a very reliable way to detect spambots that forge the From: field, so many mail sites now spam these by default.

I do agree with you - it is appalling how much power Google has. I think a bit of perspective is helpful, though.

There hasn't really been much of a span where there wasn't a de facto 900 Lb gorilla browser that threw its weight around. I think a lot of us watched this happen, but the various charts on this page are instructive:

https://en.wikipedia.org/wiki/Browser_wars

It appears that somehow the browser market trends toward an unstable near-monopoly of sorts, at least so far.

So, meet the new boss, same as the old boss. At least https everywhere is a long-term public good that they're willing to take grief over forcing. It beats some of the other unilateral changes various once-dominant browsers forced.

The complexity of the web platform is at least party to blame for this. The specifications for HTTP, HTML, DOM, CSS, JavaScript together are gargantuan and growing even further every year. This makes the development of Chrome's new competitors and the maintenance of already existing browsers extremely expensive, and it also hinders cross-browser compatibility of web applications as every browser fails to implement the monstrous specs flawlessly in its own unique ways.

We are luckier than we deserve that Mozilla exists. If it was necessary to re-implement a modern Web browser completely from scratch today, it would probably take someone with the level of commitment of Richard Stallman to make it happen.

Search engines and browser vendors have had a big influence on configuration, layout, mobile friendliness and other things long before HTTPS All The Things started to gain traction.

> a random decision by Google

It's not random and that it just might serve security is a side effect.

It is about competitive advantage over other Ad Networks which might not implement HTTPS for AdSense. It is about raising both monetary and technical cost of server setup to make Google Cloud offer look even cheaper. It is very self serving.

> 1983847813 things

And by that you mean?

Probably the dozens of various DNS, DKIM, SPF, SMTP behavior config, non-consumer-IP, etc., etc. boxes that must be ticked just right in order to not be considered a spammer these days. It's very difficult to get it all correct enough to keep a significant portion of the email sent through your SMTP site from being considered spam by mainstream email providers such as Google.

yeah, but all of these things exist becuase of the sheer amount of spam that gets sent to people.

And it still doesn't work as desired.

Gmail seems to filter all spam of mine though.

I agree that for most people, that's probably an exhausting list to go through.

I'm a fan of Hardenize. I like using that site to help people understand what needs to be done.

https://www.hardenize.com

Interesting. Thanks for the tip!

I can confirm that this is a giant pain in the ass. I use a non-standard address scheme (instead of the plus character as a tagged-address delimiter, I use the qmail approach, a dash character), so I can't easily move my domain to GMail. I occasionally end up in spam folders for reasons I can't discern, despite years of puzzling and discussion with a number of experts.

The especially frustrating thing is that there's no way to find out why you've been binned. Even my friends who work at Google can't find out for me, much less get me whitelisted.

It's not hard.

It's very difficult to get it all correct enough to keep a significant portion of the email sent through your SMTP site from being considered spam by mainstream email providers such as Google.

This doesn't change the problems of unreliable email because mail services are too aggressive, unfortunately.

We recently got a bounced mail (not dumped in a spam folder, actively rejected) from a major university, telling us that the message looked like unsolicited bulk mail. The message was sent directly to a specific single customer in response to a purchase they had just made, contained information that we were required by law to provide to them, and was sent from a reputable host with things like SPF properly set up. That is simply broken, and it is 100% the fault of the mail service admins at the university.

If it was just the occasional small site it would not be such a problem, but even iCloud (Apple) and Outlook (Microsoft) get it wrong with some regularity from hosts that check all the right boxes.

Yeah, agreed: it's all pretty broken, unfortunately.