Most apps don't support SSLKEYLOGFILE. OpenSSL, the most popular TLS library, doesn't support it.
OpenSSL does provide a callback mechanism to allow for key logging, but the application does have to opt in. IIRC, at least Curl does support it by default.
Yes, there are ways to do keylogging with OpenSSL. Even if the app doesn't support it, you can do it with LD_PRELOAD and external libraries that call those callbacks. But it's still a whole lot more work than just an env var, and then just not having all these problems in the first place, by avoiding unnecessary encryption. And it probably won't work on mobile.
It was the latest nginx at the time. I actually found a rather obscure issue on Github that touches on this problem, for those who are curious: https://github.com/kubernetes/ingress-nginx/issues/1681#issu... > We discovered a related issue where we have multiple ssl-passthrough upstreams that only use different hostnames. [...] nginx-ingress does not inspect the connection after the initial handshake - no matter if t…
That's a misunderstanding in your use of this ingress-controller "ssl-passthrough" feature. > This feature is implemented by intercepting all traffic on the configured HTTPS port (default: 443) and handing it over to a local TCP proxy. This bypasses NGINX completely and introduces a non-negligible performance penalty. > SSL Passthrough leverages SNI and reads the virtual domain from the TLS negotiation So if you want…
Thank you very much for such a clear explanation of what's happening.
Yeah, I sensed that it's not a limitation of the nginx per-se, as it was asked not to do ssl termination, hence of course it can't extract header from the scrambled bytes.
As I needed it to do grpc through asp.net, it is a kestrel requirement to do ssl termination that forced me to use the ssl-passthrough, which probably comes from a whole different can of worms.
The biggest benefit of .internal IMO is that it is free to use. Free domains used to be a thing, but after the fall of Freenom you're stuck with free subdomains.
If `.internal` is for private-use only, they must be resolved by some sort of private or internal DNS. In that case, all domains are free for private-use anyway.
Unfortunately, that's not true in general. Google proved this with their handling of the .dev TLD. Security settings like the HSTS preload list can impact your internal network if you "squat" on a domain you don't own. Google added all of .dev to the HSTS preload list and now, if you use any domain under that, you browser will force you to use HTTPS.
There's some every packet shall be encrypted, even in minimal private VPCs lore going on. I'm blaming PCI-DSS.
The big problem with running unencrypted HTTP on a LAN is that it's terribly easy for (most) LANs to be compromised. Let's start with the obvious; wifi. If you're visiting a company and ask the receptionist for the wifi password you'll likely get it. Next are eternity ports. Sitting waiting in a meeting room, plug your laptop into the ethernet port and you're in. And of course it's not just hardware, any software run…
For most purposes, when wishing for non-HTTPS, we are talking about development or maybe a staging server of some sort. Maybe if we had state secrets people would be trying to plug into the lan to snoop the traffic, but for 99.99% of developers the traffic between a testing instance and them is the most worthless thing ever. Worst case you might find out what features we will release to the app in 2 weeks. The conflation of “SSL” with “cybersecurity” is unfortunate.
Are there any good reasons to use a TLD like .internal for private-use applications, rather than just a regular gTLD like .com? It's nice that this is available, but if I was building a new system today that was internal, I'd use a regular domain name as the root. There are a number of reasons, and one of them is that it's incredibly nice to have the flexibility to make a name visible on the Internet, even if it is c…
I just got burned on my home network by running my own CA (.home) and DNS for connected devices. The Android warning when installing a self-signed CA ('someone may be monitoring this network') is fine for my case, if annoying, but my current blocker is using webhooks from a security camera to Home Assistant. HA allows you to use a self-signed cert, but if you turn on HTTPS, your webhook endpoints must also use HTTPS…
Something you may find helpful: I use a `cloudflared` tunnel to add an ssl endpoint for use outside my home, without opening any holes in the firewall. This way HA doesn’t care about it (it still works on 10.x.y.z) and your internal webhooks can still be plain http if you want.
.com is for .com. You can interpret it any way you'd like and it doesn't make a difference to anyone who isn't currently interested in the history of DNS. My preferred reading is .com for commonlymisinterpretedbypeoplewhodonotreadrfcsbutitdoesnotmatterintheslightest, which is a Welsh word meaning "oddly shaped sheep".
Isn't that proposed in RFC 920?
> Commercial, any commercial related domains meeting the second level requirements.
Certificate pinning and restricting adding custom certificates to your OS except if you're using MDM are two completely unrelated things. Overriding system trust doesn't affect certificate pinning and certificate pinning is no longer recommended anyway.
They are certainly different things, but they're not unrelated. The inability of the user to change the system trust store is part of why certificate pinning is no longer (broadly) recommended.
Certificate pinning is mainly an obstacle to using an intercepting proxy to inspect and modify the traffic of an application. If you're doing that kind of stuff you already know how to bypass the annoying OS level certificate store restrictions or how to modify an application to disable certificate pinning. The reason certificate pinning is no longer broadly recommended is because of how it makes it more difficult to rotate certificates in the case of necessity, and has nothing to do with the restrictions certain operating systems place on easy installation of your own certificates.
It's interesting that cert pinning cuts both ways though. It can also be a tool to give users power against the IT department (typically indistinguishable from malware)
Cert pinning often annoyingly works against both - software devs are a third party to both the organizational users and their IT dept overlords. Trusted computing is similar, too. It's a huge win for the user in terms of security, as long as the user owns the master key and can upload their own signatures. If not, then it suddenly becomes a very powerful form of control. The more fundamental issue is the distinction…
> The more fundamental issue is the distinction between "user" and "owner" of a computer - or its component, or a piece of software - as they're often not the same people.
Often? Only really in the case of a corporate computer. But Android locks these things down for everyone. In fact corporate owners can do things normal users can't.
For example I've heard (not confirmed) that with a Knox license you can add root CAs on Samsung. I don't think it's still possible with other MDMs or other vendors.
Protect the software from the user? Why are you giving them the software then?
Most software is tools of control and exploitation, and remains in an adversarial relationship with its users. You give software to users to make them make money for you; you protect the software from users so they don't cut you out, or use software to do something you'd rather they don't do. Software that isn't like that is in a minority, and most of it is only used to build software that is like that.
True. It's almost never to the benefit of the user. The same with "attestation" technologies.