GuidoW

5 ปีที่แล้วdiscuss

Thanks,

My use case is to get my VPS run a web and mail service on Nixos but without the bloated binary logging of journalcontrol. The indexes in these log files change heavily between snapshots so they take up way more disk space than append-only text logs, that snapshots very well on ZFS.

My experiences while building:

- It's easy to use the config.system.services tree of the user-services (ssh, bind, caddy, etc) to create s6-services;

- Sometimes it needs a change to make it work [1] on s6;

- That same change seems oblivious to systemd. I guess it just starts the process and never bothers to monitor liveness. So much for a process management system ;-)

- Nixos packagers seems overworked, as my pull requests seem to get stuck ;-(

- Nixos use of systemd leaves a lot of decisions to resolve at boot time, decisions that I want to make at build time with s6;

- However, I cannot create a s6 dependency tree specification at build time, that's still at run time;

- Because S6 uses the service-directory to store state-files in the same directory (no /etc-/var split).

1: https://github.com/NixOS/nixpkgs/pull/122844

GuidoW

5 ปีที่แล้วdiscuss

Agreed.

One point is that processes other than root cannot start services on ports < 1024. That was a sensible precaution computers where big and multiuser, like in a university setting.

However, with single-serving services (e.g. in vm/container/vps/cloud), there is no need for it.

BSD lets you configure it with a sysctl option. But Linux defends that option like it is still 1990.

On NixOS, I patch it like this:

boot.kernelPatches = [ { name = "no-reserved-ports"; patch = path/to/no-reserved-ports.patch; } ];
With the patch just as big:

--- a/include/net/sock.h +++ b/include/net/sock.h @@ -1331,7 +1331,7 @@ #define SOCK_DESTROY_TIME (10*HZ) /* Sockets 0-1023 can't be bound to unless you ares uperuser */ -#define PROT_SOCK 1024 +#define PROT_SOCK 24 #define SHUTDOWN_MASK 3 #define RCV_SHUTDOWN 1

GuidoW

5 ปีที่แล้วdiscuss

> Use NixOS and you'll love systemd.

I use NixOS but certainly not love systemd. Instead, I've created a way to replace it with s6.[1]

1: https://sr.ht/~guido/nixos-init-freedom/

Cheers, Guido.

GuidoW

5 ปีที่แล้วdiscuss

> TLS gets you an encrypted secure channel between the client and the server, and DNSSEC gives you... a signed name lookup.

I respectfully disagree with that second part. The risks for DNSSEC/DANE might be higher, the rewards are bigger too.

TLS gives me a secure channel only when I connect to the right (i.e. expected) server. A TLS encrypted and validated connection to a wrong party is the threat here.

As user, I don't know which is the CA for any given domain. And Chrome only caches a small subset. Otherwise we wouldn't need neither CAs or DANE, self signed certificates would suffice ;-)

Either I have to trust that there are vigilant parties that monitor all CT logs against fake certificates or my user agent does that for every connection, blocking when it finds double certificates.

With DNSSEC and DANE, my agent fetches the address and CA for the site and validates these against the TLS handshake.

From there, HSTS will protect future lookups so it becomes a TOFU issue.

Besides, the middle-box problem is being resolved with DOH over TLS1.3, isn't it?

GuidoW

5 ปีที่แล้วdiscuss

My beef with many chat apps is to have to authenticate with my telephone number or an email address. Both are hard to acquire in sufficient quantities for a 'normal' user.

So I came up with a decentralised authentication system.

It offers easy key exchange between total strangers. Once they create an private channel there is no way for authorities to take it back.

Here's the protocol:

Signup: - each site operates an automated CA; - an account is a nickname and public key; - the sites' CA creates a certificate binding the nickname, public key and site-root-CA together; - the user's User Agent does the hard work of the crypto.

Requirement: the nickname and public key have not been seen before, the CA rejects when either has seen before. This creates a one-to-one mapping between nicknames and public keys. This one-to-one relationship will be verified. All hell breaks lose for the automated CA that cannot comply with that simple requirement: uniqueness.

Posting messages: - users can create as many accounts at each site; - users can post public messages at that site, the messages are signed using the account's private key.

Reading messages: - the site publishes the message signature along with the message (perhaps hidden with CSS); - the user's user agent verifies the signature; - if the signature matches, (and the uniqness requirement holds) the agent offers the user the option to write a private message, encrypted using the public key that has been validated form the signature.

The reader then writes a private message to the writer of a post. The site delivers it (or not). But if yes, then we have a successful key exchange between two people who have never met in real life!

To repeat: This does not give any certainty about the person behind the signed message, all it offers is a key exchange between strangers.

This opens new avenues. Suppose the reader (of the message) starts a tor hidden service and sends the onion address to the writer. When the writer wants to, he connects to the reader, both authenticate using their private keys and set up a session key. They now have a secure channel, independent of the site. In fact, when the site gets censored, this channel remains.

I wrote a lot about it this on my site: https://eccentric-authentication.nl/

GuidoW

5 ปีที่แล้วdiscuss

The problem is that the input is parsed twice.

First by the netmask function that reads 0127 as 127 and the second time by the js-network stack code that reads it differently.

The solution is not to change netmask to ignore leading zeros. The solution is to parse it into 4 uint8 values, validate the netblock on the numeric values and if the range is approved, generate the ip-address from your four numbers. That way you know for sure that the js-network stack is going to interpret it as you intend.

There are some beautiful (horrifying) examples in this presentation: https://www.blackhat.com/docs/us-17/thursday/us-17-Tsai-A-Ne...

GuidoW

8 ปีที่แล้วdiscuss

The failure mode of TOTP, SMS is that the user needs to be sure to be connected to the correct site.

The hidden assumption is that the use is able to distinguish the fake from the correct site.

For any authentication system to work in the face of adversaries trying to confuse a user, the system needs to be robust against that.

https://eccentric-authentication.nl/blog/2014/11/30/spot-the...

https://eccentric-authentication.nl/blog/2016/11/18/on-the-i...

GuidoW

10 ปีที่แล้วdiscuss

I've designed this protocol[1] to make client certs work easy for end users.

Signing up at a site is just requesting a client cert at the site's private CA.

It requires a user agent (a browserplugin) on the client side. The agent keeps check of which certificates belong to what sites so it actively blocks MitM attacks.

Granted, if you need to share your certificates, you'd have to copy them over. For that, use the sync-feature of your browser or design something better. But synching is a separate concern, independent of the authentication protocol.

[1] http://eccentric-authentication.org/

Submissions

On the internet, there is only Alice

comments