501–510 of 525 posts
Hot take: HTTPS-only mode is a bad idea if it is not paired with first-class support for self-signed certificates authorized using DANE+DNSSec. It just forces everyone to use broken/redundant CA model.
- An error is presented only if the host offers HTTP _and_ HTTPS. - There's a nice button to just skip it and view the plain HTTP page.
Earlier quoted context omitted.
This is prevented by certificate pinning.
Yep, and HTST (if you don't trust that you can use an Firefox addon to perform certificate pinning). I believe HTST got introduced in the wake of the DigiNotar debacle (listen Darknet Diaries #3). Mitmproxy also made it easy. I guess this Mozilla Firefox change deprecates HTTPS Everywhere. Either way, we've come a long way. For people in the Dutch security world, DigiNotar was a known joke. I knew about their terribl…
I'm not familiar with HTST so I went looking but didn't find anything related to the web and HTTP, so I'm guessing you meant HSTS?
Earlier quoted context omitted.
Deploying to a mix of internal devices, many of which lack the ability to easily allow automatic certificate renewal, is not trivial.
Put a reverse proxy in front of it.
Of course it's still unsecure from your proxy to the device, but that's a more managable risk
Earlier quoted context omitted.
Yep, and HTST (if you don't trust that you can use an Firefox addon to perform certificate pinning). I believe HTST got introduced in the wake of the DigiNotar debacle (listen Darknet Diaries #3). Mitmproxy also made it easy. I guess this Mozilla Firefox change deprecates HTTPS Everywhere. Either way, we've come a long way. For people in the Dutch security world, DigiNotar was a known joke. I knew about their terribl…
> HTST I'm not familiar with HTST so I went looking but didn't find anything related to the web and HTTP, so I'm guessing you meant HSTS?
Earlier quoted context omitted.
From intermediate (MITM) caches, yes. But end-clients can still cache it though. Our market is more backend API traffic so doesn't impact as much.
Since it's becoming harder and harder to implement transparent proxies and caches, someone should define a local cache protocol so that network administrators can configure explicit shared caches for the devices on their networks.
Someone did, almost two and a half decades ago. It's called the Internet Cache Protocol.
- Internet Cache Protocol (ICP), version 2 [0]
- Application of Internet Cache Protocol (ICP), version 2 [1]
--
Earlier quoted context omitted.
I'm not sure why HN won't allow me to reply to ori_b's question below you, however DoH in Firefox (and in Chrome) have clearly spelled out ways to disable it at the network level for those folks who are network operators and want to restrict it due to interference in filtering or split-horizon DNS. https://support.mozilla.org/en-US/kb/configuring-networks-di... Someone previously mentioned Pi-Hole. Pi-Hole provides t…
The main thing I don’t want is to send all my browsing data to Cloudflare or similar “public” DNS operator outside my jurisdiction.
Earlier quoted context omitted.
GitHub, PyPi, NPM, etc are all great options for hosting dynamic content from a fixed location which looks benign to scanning. For non-tech companies, replace with any relatively popular wiki. The goal is “make a connection over HTTPS or other normal-looking protocol, to a destination that is both justifiability relevant for normal user traffic and allows the attacker to seed the next-step”. And it turns out there ar…
> GitHub, PyPi, NPM, etc are all great options for hosting dynamic content from a fixed location which looks benign to scanning. They're not going to leave malware payloads sitting there. Pastebins etc. get abused as malware command-and-control systems all the time, and of course some gets through, but countermeasures happen. Whereas for a DoH server it would be operating as designed.
The issue is “how do I tell my bootstrapper where to get a payload from in an inconspicuous way”. To solve that, you find a benign site with existing business purpose (like GitHub or a wiki or a pastebin), and you insert your desired IP address. So maybe you add it as new file in a repo under your cool new fake GitHub account, and the file just says “1.2.3.4”. Now you can tell your bootstrapper to make an HTTPS request for that file, which looks boring to any introspection because outbound requests to GitHub are normal, and to use the resulting IP to request the payload.
Your compromised payload host gets shut down? Spin up a new one, and update the file on GitHub with the new IP.
I do worry about the sort of monoculture with Let's Encrypt. A second and third provider that do the same thing would reduce the blast radius for potential outages. Grateful for LE, but there's a lot riding on it. Similar for Cloudflare.
https://www.buypass.com/ssl/products/acme This one appears fully drop in compatible with LE, except that it does not offer wildcards.
https://zerossl.com/ Does offer wildcards, but slightly less compatible, because you need to sign up with a web form, and provide your credentials via the optional ACME EAB feature (External Account Binding), so not all tooling will support it.
I’m not sure where the auto-switch from "foobar.com" to "www.foobar.com" occurs; if it’s in the browser, ideally Firefox would attempt this auto-correct first and try the HTTPS connection to the corrected location, to minimize the chance of triggering a warning.
Earlier quoted context omitted.
If only the OS could terminate TLS and allow to filter decrypted traffic locally.
IBM z/OS has an interesting feature: AT-TLS (Application Transparent TLS). An app uses the OS sockets API to create plaintext sockets, and the OS adds TLS to them (based on policies configured by the sysadmin) transparent to the application. (There are IOCTLs that apps can call to discover this is going on, turn it on/off, configure it, etc, but the whole idea is you can add TLS support to some legacy app without nee…