41–50 of 60 posts
https://www.eff.org/deeplinks/2018/02/technical-deep-dive-se...
Earlier quoted context omitted.
Why not sign it yourself?
Most people find the user experience of self-signed certificates much worse. The developer experience for local issuance isn't great, although mkcert does a really great job of smoothing the parts that can be smoothed[1]. [1]: https://github.com/FiloSottile/mkcert
This would probably be easier if I was organized enough to use at least minimal MDM features on the family's devices though, so I haven't actually completed this project yet.
Earlier quoted context omitted.
If you can't trust your network, you'll want encryption, regardless of devices on it.
if you can't trust your network, everything needs to be public internet level hardened anyway, so why not just directly use letsencrypt?
Earlier quoted context omitted.
> * If you want an SSL certificate for, say, your printer Ummmm why does my printer need a certificate?
If you're already thinking in the IPv6 mode of thought — where NAT / network-local addresses are irrelevant/obsolete, as long as there's a stateful firewall somewhere in front of your LAN devices, to treat all LAN devices as default-closed to incoming packets from outside the LAN's IPv6 network prefix... ...then (at least in theory!) there's no reason to not also give every one of those devices, with their public-rou…
one minor correction: modern (even 5-10 year old) printers do support TLS -- and they even try to push you to use it when they only have the built-in self-signed certificate. I've seen screens encouraging me to "click trust" etc. which seems idiotic to train anyone to do when the stakes of letting them admin the printer, over the LAN, over HTTP are so low. I'm so sure that a random rogue IOT device on my LAN is listening to that printer administration traffic, real high-value stuff there. Mind you that this is unrelated to whether a rogue LAN actor could sniff the actual documents being printed, since I don't think computers are typically set up to print with IPP over TLS, but use unencrypted protocols instead.
Anyway, with my HP printer, you can upload a cert and key file and that way it'll use a cert of your choice.
Earlier quoted context omitted.
if you can't trust your network, everything needs to be public internet level hardened anyway, so why not just directly use letsencrypt?
Because you don't want to expose your printer to the public Internet?
Earlier quoted context omitted.
> * If you want an SSL certificate for, say, your printer Ummmm why does my printer need a certificate?
Well yes, you've just hit on why this is a rather niche product. You get a handful of somewhat questionable benefits. If for some reason your guests are visiting your printer's administration page, they won't have to click through a scary warning page. If someone is somehow sniffing all the traffic within your home network they won't be able to get your printer's administrative password. But the main reason is some h…
If they're persistently stealing traffic from my network then the printers administrative password is the least worrisome part.
> homelab enthusiasts are like bodybuilders at the gym
Self obsessed to the point of absurdity? There was a vulnerability a few years ago where you could embed an HP Printer Firmware update into the middle of a print file by taking advantage of some insane JCL commands. You can also embed JCL commands directly into a word document.
So these researchers created a word document that when printed updates your printers firmware with a hacked version allowing an advanced persistent threat to live inside your printer.
If your printer has no anti virus or no intrusion detection then putting an SSL certificate on there is entirely pointless.
Earlier quoted context omitted.
> I guess what I’m saying is I’ve come across many cases where even bad encryption is better than plaintext Where is this? Why would bad encryption be better than plaintext? I can't imagine a scenario where this is the case.
Email is a great example of this. There's a bunch of complications like the 'to address' not matching the MX record, the MX record being served without DNSSEC, and a history of self-signed certificates. Unless you do something special you're likely transmitting email using TLS without validating the certificate. This is strictly better than plaintext as a passive eavesdropper cannot listen in; an active attack is nee…
I honestly don't know if I fully buy that argument, but there's something to be said for the idea that the problem with "better than nothing" is that it presupposes "nothing" is what you'd otherwise end up with and the crummy solution is the best you're going to get. I think your blog post highlights this point. Encrypting email even without validating certificates is better than not doing the encryption at all, but is giving people the security blanket of "at least we're doing something" slowing down the process of taking that last step?
I’ve never understood why there isn’t an easy way (ie that never expires) to use certificates or otherwise encrypt communications. I’m mainly referring to unique or internal use cases where the complications around certificates expiring has made it so that those communications end up unencrypted (SSL disabled). I guess what I’m saying is I’ve come across many cases where even bad encryption is better than plaintext,…
For an internal use case, nothing's stopping you from setting up your own CA, creating certificates that don't expire for 100 years, and telling your clients to trust them. It just takes a couple of OpenSSL commands which, while slightly complicated if you don't know what you're doing, can be easily automated with a shell script. The browser limits on maximum certificate lifetimes only apply to the public web PKI, no…
Or just use caddy as a reverse proxy [0]. This 1 line will do it all for you: myawesomedomain.com { respond "You just loaded this on https" } [0] https://caddyserver.com