411–419 of 419 posts
Earlier quoted context omitted.
Commandeering web servers will probably get you arrested ಠ_ಠ I don't know what you do with a battleship. Helm it, maybe?
No no, you only get arrested for commandeering next to another server and then boarding it.
Sounds like you'd get arrested for that....
Earlier quoted context omitted.
Your assumption about public wifi is wrong. If you connect without a password, your traffic is sent in the clear and MITM attacks are trivial. If you don't want your password exposed to any hacker with an old Pringles can within a mile of your location, you need end to end crypto.
Good to know, thanks. That seems rather negligent that per session encryption wasn't built into the protocol.
Earlier quoted context omitted.
Hmm, so let's say I'm hosting my static files on S3. I've currently got CloudFlare setup in front of it but that apparently doesn't help. Anything I can do other than not using S3?
Use CloudFront? Took me about an hour to set up for my S3 based blog, free TLS, http/2 and IPv6 without any setup apart from a checkbox.
(I'm probably understanding this wrong, but I'd like to understand why.)
I've got to say though, that this is a wee bit frustrating as a developer. SSL libraries are terrible, bug ridden, hard to work with, and there are huge sacrifices using a pass-through proxy to offer SSL. The brittleness of SSL libraries manifests not just in the form of security exploits, but also in the form of delaying the next generation of HTTP technology. Node doesn't support natively support HTTP/2 due to HTTP…
> Same with Go. Out of curiosity, what are you referring to? Go has great HTTP/2 support, and is enabled by default since 1.6. It doesn't depend on OpenSSL either, which is a big bonus in my book
Earlier quoted context omitted.
Yeah, because MITMing the origin page to submit to evil.example.org is trivial.
In such a case one would expect the evil page to present something that looked like a credit card input to the user, but not to the browser. Sites would still want to use HSTS to combat the MITMing itself.
Earlier quoted context omitted.
Well, that is the whole point I'm trying to make. Why does chrome think I'm using a password on the page when there is no password? Anyway, Chrome will mark all http as insecure sooner or later so will just have to force https on all connections... There seems to be many people with similar problems of false positives for nonexistant passwords so I guess it's a bug.
I don't really know what your point is. This will mark pages as insecure that have a ' ' field on your page. If you don't have that, you are fine. I don't know of any reasons to have a password field if it's not actually sensitive information that's being entered.
This is actually a Good Thing - with HTTPS-friendly CDN and/or Letsencrypt, rolling out sites that are secure-by-default is now easier and cheaper than ever before.
Earlier quoted context omitted.
Honestly, why would you do any of those things, now that installing a certificate takes 5 minutes and is free, with Let's Encrypt? I know that you're just exploring solutions because it's interesting, but all those things take longer than Let's Encrypt.
If the only thing you host is a small blog without ads on a server that you have complete control over and spun up last month or something, sure it's 5 minutes. In the real world, for many commercial operations, and especially for legacy code, there can be significant hurdles. For example, it took the NY Times 2 years to move to HTTPS, significantly more than 5 minutes, and they haven't even migrated 100% yet. https:…
https://www.troyhunt.com/https-adoption-has-reached-the-tipp...
TL;DR: HTTPS is now workable and affordable.