https://github.com/stealth/opmsg is a possible alternative.

Then there was Tedu’s reop experiment: https://www.tedunangst.com/flak/post/reop

Yeah, Ubiquiti’s Octeon stuff (specifically EdgeRouter) is quite well known, it’s supported by FreeBSD and OpenBSD for example. But consumer router grade CPUs are uhhhh rather weak :(

New one here, eh? :^)

Have a read, why don’t you!?

Uh, OpenBSD has ZFS? .. since when? I mean https://www.tedunangst.com/flak/post/ZFS-on-OpenBSD I mean I guess it’s sort of there, but I don’t think anyone suggests you actually USE it on OpenBSD. Regardless it’s not Notable technology from OpenBSD, they clearly don’t care for it, but like some of the features it has…

Otherwise I like this approach for “why OpenBSD” better than what is on the slides now.

Google won’t index it, for your safety, but they still cache it.

http://webcache.googleusercontent.com/search?q=cache:https://www.tedunangst.com/flak/post/books-chapter-thirteen

tedunangst.com name server ns-434.awsdns-54.com.
tedunangst.com name server ns-607.awsdns-11.net.
tedunangst.com name server ns-1775.awsdns-29.co.uk.
tedunangst.com name server ns-1312.awsdns-36.org.

Did you ask for people to add your nameservers to their resolver roots?

Domain names and RSA keys are equally scarce. It’s all protection money, for root servers and for root CAs.

For those who missed it, here is Tedu’s explanation of why he is using a self-signed HTTPS certificate: https://www.tedunangst.com/flak/post/moving-to-https. (You might have to add a temporary exception to view that page.)

Google cache have a copy here: https://webcache.googleusercontent.com/search?q=cache:https://www.tedunangst.com/flak/post/a-repo-upon-the-deep

Not all tedunangst.com submissions come from tedu, not all tedu submissions are tedunangst.com, and I don’t think it’s possible to filter out posts from a specific user like one can filter out tags?

The idea is to add the CA to the browser store. The CA is constrained to creating certs for tedunangst.org, which is nice. The weakness here is acquiring the CA in a secure way in the first place; the model is similar to SSH or signify.

Ideally you would acquire the CA out of band, like by meeting Ted in person. Good luck with that.

Unfortunately clicking through like you described loses any benefit: you’re obviously not checking the cert every time, so you’re prone to being MITMed each time you visit the site, as opposed to just the first time. (Firefox lets you save the exception, but Chrome doesn’t.)

The benefit of this over Let’s Encrypt is that if you add Ted’s CA and remove all the other CAs (that don’t have their own name constraints) from your cert store, you know that any valid HTTPS cert for tedunangst.com came from Ted and not from another compromised CA. I doubt even people who have added Ted’s CA have removed those other CAs, though, so it doesn’t seem like a real benefit to me.

Thanks for digging in. I guess we’re getting to the point where someone should roll all this up in a FAQ to get linked from every “hey site’s ssl config is broken” comment is posted on a tedunangst.com story, which is going to happen regularly for the foreseeable future.

Yep, and there are two posts about that:
https://www.tedunangst.com/flak/post/moving-to-https
https://www.tedunangst.com/flak/post/live-off-the-chain

Ah, point. You’d have to click through the warning to see why it’s safe to click through the warning.

Here is a link to the Google-cached copy of the article. That will let you read the article “moving to https” without ignoring any warnings.

Also, here is the loste.rs discussion on “moving to https”.

(He’s using a self-signed certificate, hence the warning. You can read more here)

I’m not sure what your “absolute certainty” point is? What you see when you go to tedunangst.com is a site with a certificate signed by a CA that’s not in your browser’s trusted roots - this is exactly what you get when you go to sites from CAs that were caught helping governments MitM and have therefore been removed from your browser’s trusted roots (currently only WoSign).

I wouldn’t mind importing the CA, but how well does the name constraint work in Firefox?

        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:TRUE
            X509v3 Name Constraints: 
                Permitted:
                  DNS:.tedunangst.com

This is actually cool if it works!

It’s not a broken or dodgy cert. The difference is the trust model that @tedu is using. He is asking users to put trust in him vs a CA (https://www.tedunangst.com/flak/post/moving-to-https - I know you can’t see it without the cert). The important part is this:

Yesterday, reading this page in plaintext was perfectly fine, but today, add some AES to the mix, and it’s a terrible menace, unfit for even casual viewing.

The difference now is that your browser paints a terrifying UI vs rendering stuff with a cert it doesn’t know about.

The model he is using is similar to SSH’s “Trust on first use” but with a few extra steps to cope with the UI that operates via the “Trust anything from these guys, they are totally OK, right? RIGHT?” model.

Anyway, here is the cert, a sha256 sum and its sha256 fingerprint of it if you feel like importing it into your browser:

-----BEGIN CERTIFICATE-----
MIID2TCCAsGgAwIBAgIJAJIn/VMsBJrpMA0GCSqGSIb3DQEBCwUAMHMxCzAJBgNV
BAYTAlVTMQswCQYDVQQIDAJQQTEXMBUGA1UECgwOdGVkdW5hbmdzdC5jb20xGjAY
BgNVBAMMEWNhLnRlZHVuYW5nc3QuY29tMSIwIAYJKoZIhvcNAQkBFhN0ZWR1QHRl
ZHVuYW5nc3QuY29tMB4XDTE3MDcxMzIzNTMwNloXDTIxMDQwODIzNTMwNlowczEL
MAkGA1UEBhMCVVMxCzAJBgNVBAgMAlBBMRcwFQYDVQQKDA50ZWR1bmFuZ3N0LmNv
bTEaMBgGA1UEAwwRY2EudGVkdW5hbmdzdC5jb20xIjAgBgkqhkiG9w0BCQEWE3Rl
ZHVAdGVkdW5hbmdzdC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQC3uH7heRPPoxNFbhmHBbXzMqEClGxtEPaqVi6/owmviK5Yk7AvQ4ro5F740znk
fwno8tj5RPjDUpIBJkpBKBdTg23pHZOHAmioK11g0V6E8GIebKHvQi/iI/NCIRtq
+hfMCrwsfdX5lOE9HJyaiamdXrDUR1PNA4G7EEUamnVQqOT9+Y7Bbh2qaxvJ6bjw
43ytgzbDYUAFrsAiAzydPqX+FSQBTrB+pea2MEzNuevZFmBMdGUfvIHTmnp+PmUD
r/flLsDKaMNZL8HK4KydI0eInrTuoI9kd+Zu3L4ZmQVOTt7XV0ezHsROrqOxwpqd
9a1DCVXvOnuHuN7UwgYZIQ/XAgMBAAGjcDBuMAwGA1UdEwQFMAMBAf8wHgYDVR0e
BBcwFaATMBGCDy50ZWR1bmFuZ3N0LmNvbTAdBgNVHQ4EFgQUkrTp53Wxxq82rhLk
ltMCZGIQRQ0wHwYDVR0jBBgwFoAUkrTp53Wxxq82rhLkltMCZGIQRQ0wDQYJKoZI
hvcNAQELBQADggEBAKIOxuH4fMiiZXgL6ABUIzpmDWNQVYN89svUwezAOGbs8WV1
rTzoGBVoKwsXoiCI49nWdKaVMdOfoKUgmq2TrF3mST7+D/py+4XPPiJwcekOlwJ0
LJT41D1urH2YyGRz9vNFLeFmgwvQLExqWbOhPRG0YOoGR5W41JtVOyTsll6Z0qbQ
jkWBj/g5g8slVISfCKP7pH3CVmEUGbbZd5FiUrR+WDP9XOrPDsneX4/XkbLZ+ZNH
Z+RxNGlJ6txIQcSTmtsQqHTLdKRoAWT7YxmvPB9pfZ8bDsRSNjohF0QkxM0Y9qxf
Xf7xlhGJs7KkNn4LteI5vwjf+9U6Wtbm/Vr5MsU=
-----END CERTIFICATE-----

SHA256 (ca-tedunangst-com.crt) = 049673630a4a8d801a6c17ac727e015fbf951686cdd253d986e9e4d1a8375cba

SHA-256 Fingerprint	AA DD 6D 06 88 7B 36 60 67 56 00 AB D0 76 FB B4
			3C 60 10 14 5D AB 4D 39 06 F8 24 08 4B 14 D2 BE

I have also signed this message using my pgp stuffs. I guess this means we have a lobste.rs based web of trust using the Comments protocol?

The real question in all of this shouldn’t be “why is @tedu using broken / dodgy certs”, it should be: Who do you trust more?

Raw post / sig: https://deftly.net/lpost.txt https://deftly.net/lpost.txt.asc

PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A 4AF0 1F81 112D 62A9 ADCE

@tedu - I may be misunderstanding what’s going on but it seems the root cert doesn’t work with libressl.

# openssl x509 -text -in ca-tedunangst-com.crt >> /etc/ssl/cert.pem 
$ nc -c www.tedunangst.com 443
nc: tls handshake failed (certificate verification failed: permitted subtree violation)

Possibly this openssl bug, patched here but it doesn’t look like libressl has that patch.

To intercept traffic now, with a custom cert, they need to replace your download. Then they need to use that cert to sign the cert actually used for the web server. And they probably need to replace the sha256 on the home page or somebody might notice what’s up. So this gets pretty complicated and needs to be customized for every site.

It’s as custom for the ISP as it is for the host and for the user. Any standardized way of doing this, the ISP can get a turnkey solution that will MITM for them. Any nonstandardized way of doing this is too tedious for the user to work with.

And then there’s the possibility that you’ve already downloaded the cert at some time in the past. Intercepting traffic now is a fairly risky gambit. The naughty ISP needs to commit to intercepting before they even know what file you’re downloading.

How is it a risk? The user sees a certificate with no connection to any known root, which could have been created by anyone. Someone between me and tedunangst.com is malicious, sure, there are a lot of malicious people on the internet, that’s not the ISP’s fault. There’s no accountability.

SHA256 (ca-tedunangst-com.crt) = 049673630a4a8d801a6c17ac727e015fbf951686cdd253d986e9e4d1a8375cba

That’s posted on the home page. It’s not included in the flak post following the principle that important information should only be maintained in one place. I’ve added a note and a link. That was an oversight.

It’s the hash of the file, not some internal fingerprint, because I find that easier to verify with simpler tools. You don’t even need to decode it to at least verify it’s the same file I say it is.