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

Plaintext HTTP in a Modern World

jcs.org

Post reply on HN
Print view View original

51–60 of 78 posts

Re: Plaintext HTTP in a Modern World

#51

Post by Lex-2008 »

KronisLV wrote: post #20
superkuh wrote: post #2

Everything in this article rings true. But there's more. HTTPS only, combined with almost everyone only using LetsEncrypt (a great service), leads to massive concentration of value for any internal corruption at LE or external political (or other) pressures on LE. The more browsers refuse to show HTTP, the more people in LE, the greater prize it is for those that want to control what is seen. If you want the web to b…

> HTTPS only, combined with almost everyone only using LetsEncrypt (a great service), leads to massive concentration of value for any internal corruption at LE or external political (or other) pressures on LE. Well where are all the other free SSL/TLS certificate providers, then? ZeroSSL sometimes gets mentioned, though they are also pretty keen to charge you, which is the exact reason why many go for Let's Encrypt:…

well, to be fair, https://zerossl.com/pricing/ has a "free" column :)

On the other page, https://zerossl.com/features/acme/ it looks like free acme certificates can have a wildcard records (*.example.com).

https://www.sslforfree.com/ claims they use zerossl and support wildcard records.

Also, one of others you mentioned also has a free acme option, but without mentioning wildcards: https://www.ssl.com/how-to/order-free-90-day-ssl-tls-certifi...

Re: Plaintext HTTP in a Modern World

#52

Post by zhfliz »

Macha wrote: post #15
superkuh wrote: post #2

Everything in this article rings true. But there's more. HTTPS only, combined with almost everyone only using LetsEncrypt (a great service), leads to massive concentration of value for any internal corruption at LE or external political (or other) pressures on LE. The more browsers refuse to show HTTP, the more people in LE, the greater prize it is for those that want to control what is seen. If you want the web to b…

I believe there's three or four well accepted ACME providers now, which is why a lot of tools now support or even default to alternative vendors, partly to mitigate this concern. e.g. acme.sh will try ZeroSSL first, Caddy will rotate between ZeroSSL and Let's Encrypt.

acme.sh moving to ZeroSSL has nothing to do with increasing variety.

acme.sh moved to ZeroSSL as default due to being sponsored by them.

my primary reason for avoiding ZeroSSL is the requirement of providing an email address to them that can be abused.

Re: Plaintext HTTP in a Modern World

#53

Post by astrobe_ »

jbotdev wrote: post #6

Not sure I understand the concern about access from “modern embedded devices”. Something like a Raspberry Pi, or really anything with a decent ARM processor, can easily handle TLS.

The word "modern" in the phrase is dumb -- as usual with the word modern; it's on of those word that convey no real meaning most of the times. It's not about modern, it's about power.

Current 32bits SoCs prolly sale for the same price as 16bits systems of a decade ago, so yes, they probably can handle HTTP. However, 8 and 16 bits microcontrollers with only a few kb of RAM/Flash are still made ("modernly"), sold and used - and those cannot handle HTTPS.

Re: Plaintext HTTP in a Modern World

#54

Post by tialaramex »

aliraheem wrote: post #4
superkuh wrote: post #2

Everything in this article rings true. But there's more. HTTPS only, combined with almost everyone only using LetsEncrypt (a great service), leads to massive concentration of value for any internal corruption at LE or external political (or other) pressures on LE. The more browsers refuse to show HTTP, the more people in LE, the greater prize it is for those that want to control what is seen. If you want the web to b…

I may be wrong, but as I understand it HTTPS connections typically use an ephemeral key with the certificate used to authenticate the servers identity. So simply having the certificate does not mean one can read the traffic without conducting a man-in-the-middle attack. This means that anyone who could read traffic from a HTTPS connection could read it from a HTTP connection just as easy. The arguement seems to boil…

Not just typically. All the uses, even with older protocols, use ephemeral keys to secure the HTTP transaction.

Even the most awful RSA kex (using the RSA algorithm to just encrypt a random key and send it to the other party, rather than doing a Diffie-Hellman key exchange of any kind) is still ephemeral keys and still cannot be decrypted by a CA. It's terrible because it has no Forward Secrecy, but it would not fall to this imaginary attack.

With Forward Secrecy (always in TLS 1.3 and if you didn't deliberately choose insecure options in TLS 1.2 and earlier) even if your adversary kept a transcript of the encrypted transaction and they later obtain your actual private key, that's still no enough to decrypt the transaction because the transaction key was ephemeral.

In fact the CA deliberately by policy must not have the private key needed to do more. If anybody has evidence of a present day Certificate Authority either asking for their private key [other than for a "Key compromise" type event where the certificate gets invalidated] or of them providing a mechanism by which they "randomly" choose your key and would have an opportunity to just remember it - tell m.d.s.policy https://groups.google.com/a/mozilla.org/g/dev-security-polic...

Your processes shouldn't open you to such an attack (private keys should ideally never leave the machines using them) but it's also policy that the CA shouldn't want to ever know these keys. Not least because this would make them a target.

Re: Plaintext HTTP in a Modern World

#55

Post by Joel_Mckay »

In general, browsers default security policy force a valid “https” connection to allow access to even the most rudimentary functionality. Admittedly SSL doesn’t stop every issue, especially considering the number of times issuers were caught signing bogus content (Symantec, Microsoft, and so on…). However, it does narrow the number of variables when tracking down 3rd party issues like ISPs fiddling with content.

1. disable crossorigin on your server if you can manage without..

2. hash sign static included javaScript and CSS files (for CDN services this is good practice):

cat file.js | openssl dgst -sha384 -binary | openssl base64 -A

In your html/script add content include tag check:

... script src="file.js" integrity="theHash" …

3. Force re-encode of media in a temporary VM instance: strips all user media files of non-media data/metadata to protect people from themselves, mitigates adversarial nuisances, and ensures format conforms to a known standard.

4. DNS over HTTPS (DoH) is an option now, and recommended in many cases

5. DNS Security Extensions (DNSSEC) can be a huge resource drain for high-traffic sites.. YMMV.. sometimes a necessary evil to turn it off..

6. Should one ever allow users to upload compressed archives, unidentified binaries, webp, SVG, fonts, or TIFF? https://www.youtube.com/watch?v=pmePLg3hdCw

7. Sanitize your input data with standard filters, and never trust the input content.. even your own (both client and server side checking of data).

8. Traffic shaping firewall to force dropping clients outside a "normal" traffic service range/session-time.

9. Interface transaction quota limit tripwire, and firewall service abuse breaker logic

This is hardly an exhaustive list, but will often reduce common nuisances. ;-)

Re: Plaintext HTTP in a Modern World

#56

Post by shaicoleman »

marginalia_nu wrote: post #49
shaicoleman wrote: post #46

Earlier quoted context omitted.

That only happens if you directly visit a malicious site, e.g. https://secure.mybaaankingsite.com You can protect yourself by going directly to the URL and checking you're on the right domain. If you don't enforce HTTPS everywhere, any website is potentially malicious, e.g. visiting http://cookierecipes.com can have the same consequences.

Right, but how do I know whether the URL pattern is legitimate? I don't work for the IT department at my bank. If the answer is to just eyeball it, that does seem like a far worse security problem than HTTP has ever been.

HTTPS isn't a panacea for all security issues. It ensures that when you connect to website.com, you'll get whatever website.com sends to you, without anyone else eavesdropping and tampering with the connection.

HTTPS doesn't prevent you from going to weebsite.com. There are other security measures for that, but it's also your responsibility to check.

Re: Plaintext HTTP in a Modern World

#57

Post by LunaSea »

marginalia_nu wrote: post #47
LunaSea wrote: post #44

Earlier quoted context omitted.

TLS protects completely against network based MitM attacks. CDNs are purposefully installed in MitM positions. That's a risk that the sites owner has to manage and it's an optional one at that. A well funded actor would probably use different kind of vectors and not even bother with website MitM.

So why does catmemes.lol need to be encrypted with such urgency?

Because random ISPs will inject ads in websites for example.

Re: Plaintext HTTP in a Modern World

#58

Post by marginalia_nu »

shaicoleman wrote: post #56
marginalia_nu wrote: post #49

Earlier quoted context omitted.

Right, but how do I know whether the URL pattern is legitimate? I don't work for the IT department at my bank. If the answer is to just eyeball it, that does seem like a far worse security problem than HTTP has ever been.

HTTPS isn't a panacea for all security issues. It ensures that when you connect to website.com, you'll get whatever website.com sends to you, without anyone else eavesdropping and tampering with the connection. HTTPS doesn't prevent you from going to weebsite.com. There are other security measures for that, but it's also your responsibility to check.

It doesn't even do the first thing. There are multiple vectors where someone could tamper or eavesdrop on a HTTPS connection, perhaps the biggest one being CDNs. As a visitor, you have no real idea how secure the connection is, even if it has a "padlock". HTTPS offers some protection against local attack vectors, from your ISP or on a public WiFi, but that's about it. The server could be compromised, or malicious, you have no idea.

Putting the responsibility for checking the rest on the user is honestly a mistake. They could be dyslexic, and may not be able to detect a typo. They could also be 85 years old and not understand half of what you are saying. These are the problems browsers should be focusing on. Security is not as easy as encrypting the protocol and saying everything else is user error.

Re: Plaintext HTTP in a Modern World

#59

Post by marginalia_nu »

LunaSea wrote: post #57
marginalia_nu wrote: post #47

Earlier quoted context omitted.

So why does catmemes.lol need to be encrypted with such urgency?

Because random ISPs will inject ads in websites for example.

That seems like a poor choice of ISP to me. If I dial my phone and have to listen to ad jingles before it connects, I'm changing my phone company.

Re: Plaintext HTTP in a Modern World

#60

Post by leonth »

oneplane wrote: post #13

This page doesn't seem to grasp the reasons behind using encrypted connections. It's not some 'security' blanket statement or 'have something to hide', it's tamper-prevention (including MITM malware injection), privacy, and a little bit of identity verification (not really something people do in the real world). https://www.troyhunt.com/heres-why-your-static-website-needs... If your problem is some ancient device tha…

I thought the whole reason for encrypted connections is to deny information as much as possible from intermediaries (ISPs), so those who control servers can hoard all the information to their own benefit?
Post reply on HN