281–290 of 345 posts
Service workers are a poor replacement for the shared HTTP cache, since the cache will not be shared among users.
Earlier quoted context omitted.
In my testing for high-throughput scenarios like copies over ssh/rsync/https/smb (i tried them all) in every case encryption was a big hit to throughput. hardware assistance (built into the CPU) helped a lot but it was still a massive boost to shut off encryption - saving literal minutes on every bulk transfer, multiple transfers per day. For the average case it probably doesn't matter, and you can optimize it, but I…
How long ago was this — and how fast was your network? On hardware less than a decade old you shouldn’t be seeing that unless you’re talking about 10+Gb networking.
One potentially good reason to not force SSL: https://meyerweb.com/eric/thoughts/2018/08/07/securing-sites... TL;DR: Secure websites can make the web less accessible for those who rely on metered satellite internet (and I'm sure plenty of other cases).
Earlier quoted context omitted.
This is probably a bad idea and I'd recommend migrating off such names as a background task. Realistically you can't entirely deconflict these names. So you always have a risk of shadowing names from the public Internet. The public CAs spent years in denial over this (yes they used to sell publicly trusted certs for "private" names, this is now prohibited). Create internal.example.com and things get easier. To the ex…
> Realistically you can't entirely deconflict these names. So you always have a risk of shadowing names from the public Internet. It's totally save and legitimate for ycombinator to use secret.ycombinator.com on their intranet without telling anything about it to the outside internet.
The grandparent was, as I understand it, talking about names they don't own, for which you've no assurance somebody else won't own them (on the public Internet) tomorrow. This used to be very common, decades ago Microsoft even advised corporations to do it for their AD, but it's a bad idea.
Earlier quoted context omitted.
In other words, "open users up to social engineering attacks to make my web-dev life easier".
You misinterpreted the above commenter. The suggestion is to disallow self-signed contexts access cookies set in authoritative contexts.
> ...disable secure cookies ... for self-signed certs. ... the user ... enable[s] them.
So you make a self-signed cert for your website which needs secure login, and you tell your users to turn on secure cookies so that you can safely store their credentials in the browser. Then your website gets MITM'ed with another self-signed cert, which either
1. can access the same cookies, because the domain is the same
2. can't, because the cert is different
1. The requirement to involve a 3rd party certificate authority is a needless power grab. Giving in ends the hope that it will ever get changed. 2. There is currently only one free cert provider, if there are ever issues with it, your users will see a scary error message which will make them think there are security issued with your website. 3. Downloading and running code from a 4th, or 5th party and giving it acces…
If you dont get the difference in scale between the two you might have an issue understanding the real problem.
Earlier quoted context omitted.
Do you have a description of how you made your own security and what it provides?
Last time I described it here on HN there was confusion. It's just "single serving server salt" (try saying that fast 3 times) sent to "client for secret hashing" and then "sent back to server again", so it's insecure on registration (just like all security with MITM without common pre-shared secret) but after that it's pretty rock solid, even quantum safe. Requires two request/responses per auth. though. This tech i…
If someone presents as your web site to a first time visitor (or a previous visitor but on a new device), there is no way for them to really trust your web site. Basically, it's the equivalent of you using self-signed certs, and likely even worse because there are more attack vectors even outside the initial connection.
Earlier quoted context omitted.
How exactly is it a pain in the ass? - If you are hosting a simple static page or blog, your hosting provider probably has Let's Encrypt plugin. - If you have your own VPS, Caddy has you covered with file serving, fastcgi support for PHP, and proxying to (g)unicorn/nodejs/Go/.NET, and has HTTPS enabled by default. - If you have more advanced setup (e.g. containers), traefik supports HTTPS with just a few lines of con…
1) Not everything is running bare Apache. In fact, some services might have some rather strange web-driven GUI (or, more interestingly, curses-like) that requires you to carefully load a certificate, a CSR, and so forth in a somewhat arcane manner. Some pretty niche serving exists out there and I have had to deal with a bunch of them, to the point where I had to write extensive documentation on keeping the certificat…
So you are being forced to either not serve http, or to condition users to trust MITM-able redirect. How many people will notice a typoed redirect to an https page with a good certificate?
The solution is simple: browsers should default to https, and fall back to http if unavailable. Sure, some sites have broken https endpoints, but browsers have enforced crazier shit recently.