Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTTPS by default

security.googleblog.com

Post reply on HN
Print view View original

101–110 of 268 posts

Re: HTTPS by default

#101

Post by duskwuff »

_23sd wrote: post #9
dist-epoch wrote: post #5

> HTTPS adoption expressed as a percentage of main frame page loads Why is Linux adoption at 80% when MacOS/Android/Windows are at 95%? Quite unexpected.

This is addressed in the article. > If you exclude navigations to private sites, then the distribution becomes much tighter across platforms. In particular, Linux jumps from 84% HTTPS to nearly 97% HTTPS when limiting the analysis to public sites only. Sounds like it's just because a large chunk of Linux usage is for web interfaces on the local machine or network, rather than everyday web browsing.

Speculation, but: there are probably quite a few Linux systems displaying internal dashboards over HTTP, with the page set to auto-refresh.

Re: HTTPS by default

#102

Post by tracker1 »

kaoD wrote: post #97
tracker1 wrote: post #96

Earlier quoted context omitted.

My work laptop has a CA from the organization installed and all HTTP(S) traffic is passed through a proxy server which filters all traffic and self-signs all domains with its' CA. It's relatively common for larger organizations. I've seen this in govt and banking.

I know it's common, but I don't think it's "normal" even if it has been "normalized". I wouldn't subject myself to that. If my employer doesn't trust me to act like an adult I don't think it's the place for me. I could maybe understand it for non-tech people (virus scanning yadda yadda) but for a tech person it's a nuisance at best.

So you want to double the infrastructure surface to provide a different route for access for developers which may be a tiny portion of users in an organization? That's privilege right there.

Edit: I'm not saying I like it this way... but that's what you get when working in a small org in a larger org in a govt office. When I worked in a security team for a bank, we actually were on a separate domain and network. I generally prefer to work untrusted, externally and rely on another team for production deployment workflows, data, etc.

Re: HTTPS by default

#103

Post by zamadatix »

isodev wrote: post #86
Arainach wrote: post #83

Earlier quoted context omitted.

The threat model of HTTP isn't site owners, it's that anyone else can change the content and you can't tell that it didn't come from the original site. It's not a strawman, it's a real attack that we've seen for decades. The entire guidance of "don't connect to an open wireless AP"? That's because a malicious actor who controlled the AP could read and modify your HTTP traffic - inject ads, read your passwords, update…

Then perhaps the problem is open APs? There are still legitimate uses for HTTP including reading static content. Say we all move to HTTPS but then let’s encrypt goes away, certificate authority corps merge, and then google decides they also want remote attestation for two way trust or whatever - the whole world becomes walled up into an iOS situation. Even a good idea is potentially very bad at the hands of unregulat…

> Then perhaps the problem is open APs?

The problem in the above was not actually caused by the AP being open, nor is it just limited to APs in the path between you and whatever you're trying to connect to on the internet. Another common example is ISPs which inject content banners into unencrypted pages (sometimes for billing/usage alerts, other times for ads). Again, this is just another example - you aren't going to whack-a-mole an answer to trusting everything a user might transit on the internet, that's how we came to HTTPS instead.

> There are still legitimate uses for HTTP including reading static content.

There are valid reasons to do a lot of things which don't end up making sense to support in the overall view.

> Say we all move to HTTPS but then let’s encrypt goes away, certificate authority corps merge, and then google decides they also want remote attestation for two way trust or whatever - the whole world becomes walled up into an iOS situation. Even a good idea is potentially very bad at the hands of unregulated corps (and this is not a hypothetical)

There are at least 2 other decent sized independent ACME operators at this point, but say all of the certificate authority corps merge but we planned ahead and kept HTTP support: our banking/payments, sites with passwords, sites with PII, medical sites, etc is in a stranglehold but someone's plain text blog post about it will be accessible without a warning message. Not exactly a great victory, we'll still need to solve the actual problem just as desperately at that point.

.

The biggest gripe I have with the way browsers go about this is they only half consider the private use cases, and you get stuck with the rough edges. E.g. here they call private addresses out to not get a warning, but my (fully in browser, single page) tech support dump reader can't work when opened as a file:/// because the browser built-in for calculating an HMAC (part of WebCrypto) is for secure contexts only, and file:/// doesn't qualify. Apart from being stupid because they aren't getting rid of JavaScript support on file:/// origins until they just get rid of file:/// completely and it just means I need a shim, it's also stupid because file:/// is no less a secure origin than localhost.

I'd like for every possible "unsecure" private use case to work, but I (and the majority of those who uses a browser) also has a conflicting want to connect to public websites securely. The options and impacts for these conflicting desires have to be weighed and thought through.

Re: HTTPS by default

#104

Post by kaoD »

tracker1 wrote: post #102
kaoD wrote: post #97

Earlier quoted context omitted.

I know it's common, but I don't think it's "normal" even if it has been "normalized". I wouldn't subject myself to that. If my employer doesn't trust me to act like an adult I don't think it's the place for me. I could maybe understand it for non-tech people (virus scanning yadda yadda) but for a tech person it's a nuisance at best.

So you want to double the infrastructure surface to provide a different route for access for developers which may be a tiny portion of users in an organization? That's privilege right there. Edit: I'm not saying I like it this way... but that's what you get when working in a small org in a larger org in a govt office. When I worked in a security team for a bank, we actually were on a separate domain and network. I ge…

Indeed I'm quite privileged.

I'm lucky to be a dev both by trade and passion. I like my job, it's cozy, and we're still scarce enough that my employer and I are in a business relationship as equals: I'm just a business selling my services to another business under common terms (which in my case include trusting each other).

Re: HTTPS by default

#105

Post by marginalia_nu »

giancarlostoro wrote: post #65
marginalia_nu wrote: post #17

http://www.slackware.com/ is probably the biggest website I'm aware of that does not serve encrypted traffic[1]. but there are a few other legitimately useful resources that don't encrypt. [1] (Except on the arm subdomain for some reason)

My first distro was Slackware. Good memories. The ARM subdomain looks drastically more maintained, posts from 2025. Don't ever view source on slackware.com

> Don't ever view source on slackware.com

That's very 90s looking HTML. Large swathes of blank spaces may also indicate they're rendered somehow. PHP? CGI?

Confusingly it also sets an akamai cookie, `ak_bmsc`. Seems a bit out of place.

Re: HTTPS by default

#106

Post by 1vuio0pswjnm7 »

sam_lowry_ wrote: post #12
tialaramex wrote: post #7

I have had HTTPS-by-default for years and I can say that we're past the point where there's noticeable year-to-year change for which sites aren't HTTPS. It's almost always old stuff that pre-dates Let's Encrypt (and presumably just nobody ever added HTTPS). The news site which stopped updating in 2007, the blog somebody last posted to in 2011, that sort of thing. I think it's important to emphasise that although Tim'…

I run my blog in unencrypted HTTP/1.1 just to make a point that we do not have to depend on third parties to publish content online. And I noticed that Whatsapp is even worse than Chrome, it opens HTTPS even if I share HTTP links.

That's a good point to make, IMHO

What is funny about HTTPS is that early arguments for its existence IIRC were often along the lines of protecting credit card numbers and personal information that needed to be sent during e-commerce

HTTPS may have delivered on this promise. Of course HTTPS is needed for e-commerce. But not all web use is commercial transactions

Today, it's unclear who or what^2 HTTPS is really protecting anymore

For example,

- web users' credit card numbers are widely available, sold on black markets to anyone; "data breaches" have become so common that few people ask why the information was being collected and stored in the first place nor do they seek recourse

- web users' personal information is routinely exfiltrated during web use that is not e-commerce, often to be used in association with advertising services; perhaps the third parties conducting this data collection do not want the traffic to be optionally inspected by web users or competitors in the ad services business

- web users' personal information is shared from one third party to another, e.g., to "data brokers", who operate in relative obscurity, working against the interests of the web users

All this despite "widespread use of encryption", at least for data in transit, where the encryption is generally managed by third parties

When the primary use of third-party mediated HTTPS is to protect data collection, telemetry, surveillance and ad services delivery,^1 it is difficult for me to accept that HTTPS as implemented is primarily for protecting web users. It may benefit some third parties financially, e.g., CA and domainname profiteers, and it may protect the operations of so-called "tech" companies though

Personal information and behavioral data are surreptitiously exfiltrated by so-called "tech" companies whilst the so-called "tech" company's "secrets", e.g., what data they collect, generally remain protected. The companies deal in information they do not own yet operate in secrecy from its owners, relentlessly defending against any requests for transparency

1. One frequent argument for the use of HTTPS put forth by HN commenters has been that it prevents injection of ads into web pages by ISPs. Yet the so-called "tech" companies are making a "business" out of essentially the same thing: injecting ads, e.g., via real-time auctions, into web pages. It appears to this reader that in this context HTTPS is protecting the "business" of the so-called "tech" companies from competition by ISPs. Some web users do not want _any_ ads, whether from ISPs or so-called "tech" companies

2. I monitor all HTTPS traffic over the networks I own using a local forward proxy. There is no plaintext HTTP traffic leaving the network unless I permit it for a specific website in the proxy config. The proxy forces all traffic over HTTPS

If HTTPS were optionally under user control, certainly I would be monitoring HTTPS traffic being automatically sent from own computers on own network to Google by Chrome, Android, YouTube and so on. As I would for all so-called "tech" companies doing data collection, surveillance and/or ad services as a "business"

Ideally one would be able to make an informed decision whether they want to send certain information to companies like Google. But as it stands, with the traffic sometimes being protected from inspection _by the computer owner_, through use of third party-mediated certificates, the computer owner is prevented from knowing what information is being sent

In own case, that traffic just gets blocked

Re: HTTPS by default

#107

Post by antisol »

ottah wrote: post #91

Mmmm, great that and mandatory key rotation every 90 days, plus needing to get a cert from an approved CA, means just that more busy work to have an independent web presence. I don't like people externalizing their security policy preferences. Yes this might be more secure for a class of use-cases, but I as a user should be allowed to decide my threat model. It's not like these initiatives really solve the risks pose…

Impressive. I don't need to post my opinion on this anymore - you did it so much better than I ever could.

Re: HTTPS by default

#108

Post by antisol »

noirscape wrote: post #32
shadowgovt wrote: post #13

Earlier quoted context omitted.

Silly question and one I should probably already know the answer to but never really got around to thinking through: are there practical concerns for not doing TLS in your home intranet? It means that if someone has patched into your local network they can access anything in there, but they have to get in first, right? So how concerned should one be in these scenarios (a) one has wifi with WPA2 enabled (b) there's a…

Main reason is that it's hard to get certificates for intranets that all devices will properly trust. Public CAs don't issue (free) certificates for internal hostnames and running your own CA has the drawback that Android doesn't allow you to "properly" use a personal CA without root, splitting it's CA list between the automatically trusted system CA list and the per-application opt-in user CA list. (It ought to be n…

If someone is in your LAN then you have bigger problems than them snooping on you while you talk to your fridge.

Re: HTTPS by default

#109

Post by greatgib »

dadrian wrote: post #85
tialaramex wrote: post #75

Earlier quoted context omitted.

ISRG (Let's Encrypt's parent entity) wrote Certbot, initially under the name "letsencrypt" but it was quickly renamed to be less confusing, and re-homed to the EFF rather than ISRG itself. So, what you've said is true today, but historically Certbot's origin is tied to Let's Encrypt, which makes sense because initially ACME isn't a standard protocol, it's designed to become a standard protocol but it is still under d…

Yes, it started that way, but complaining about the current auto-update behavior of the software (not the ACME protocol), is completely unrelated to Let's Encrypt and is instead an arbitrary design decision by someone at EFF.

As far as I remember, since the beginning certbot/let's encrypt client was a piece of crap especially regarding the autodownload and autoupdate (alias autobreak) behavior.

And I couldn't praise enough acme.sh at the opposite that is simple, dependency less and reliable!

Re: HTTPS by default

#110

Post by Uvix »

michaelt wrote: post #88
vhcr wrote: post #21

Earlier quoted context omitted.

Depend on one less third party, you still depend on the DNS Root servers, your ISP / hosting, domain registry, etc.

CAs are uniquely assertive about their right to cut off your access. My hosting provider may accidentally fuck up, but they'll apologise and fix it. My CA fucks up, they e-mail me at 7pm telling me I've got to fix their fuck-up for them by jumping through a bunch of hoops they have erected, and they'll only give me 16 hours to do it. Of course, you might argue my hosting provider has a much higher chance of fucking u…

CAs have to follow the baseline rules set by Google and Mozilla regarding incident response timelines. If they gave you more time, the browsers would drop them as a supported CA.
Post reply on HN