infrastructure/mox
1
0
Fork 0
mirror of https://github.com/mjl-/mox.git synced 2025-07-14 05:34:38 +03:00
Code Issues Packages Projects Releases Wiki Activity

implement tls client certificate authentication

Browse Source 
the imap & smtp servers now allow logging in with tls client authentication and
the "external" sasl authentication mechanism. email clients like thunderbird,
fairemail, k9, macos mail implement it. this seems to be the most secure among
the authentication mechanism commonly implemented by clients. a useful property
is that an account can have a separate tls public key for each device/email
client.  with tls client cert auth, authentication is also bound to the tls
connection. a mitm cannot pass the credentials on to another tls connection,
similar to scram-*-plus. though part of scram-*-plus is that clients verify
that the server knows the client credentials.

for tls client auth with imap, we send a "preauth" untagged message by default.
that puts the connection in authenticated state. given the imap connection
state machine, further authentication commands are not allowed. some clients
don't recognize the preauth message, and try to authenticate anyway, which
fails. a tls public key has a config option to disable preauth, keeping new
connections in unauthenticated state, to work with such email clients.

for smtp (submission), we don't require an explicit auth command.

both for imap and smtp, we allow a client to authenticate with another
mechanism than "external". in that case, credentials are verified, and have to
be for the same account as the tls client auth, but the adress can be another
one than the login address configured with the tls public key.

only the public key is used to identify the account that is authenticating. we
ignore the rest of the certificate. expiration dates, names, constraints, etc
are not verified. no certificate authorities are involved.

users can upload their own (minimal) certificate. the account web interface
shows openssl commands you can run to generate a private key, minimal cert, and
a p12 file (the format that email clients seem to like...) containing both
private key and certificate.

the imapclient & smtpclient packages can now also use tls client auth. and so
does "mox sendmail", either with a pem file with private key and certificate,
or with just an ed25519 private key.

there are new subcommands "mox config tlspubkey ..." for
adding/removing/listing tls public keys from the cli, by the admin.
This commit is contained in:
Mechiel Lukkien
2024-12-05 22:41:49 +01:00
parent 5f7831a7f0
commit 8804d6b60e
38 changed files with 2737 additions and 309 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
smtpclient/client.go
View File

@ -109,10 +109,11 @@ type Client struct {
tlsVerifyPKIX bool
ignoreTLSVerifyErrors bool
rootCAs *x509.CertPool
remoteHostname dns.Domain // TLS with SNI and name verification.
daneRecords []adns.TLSA // For authenticating (START)TLS connection.
daneMoreHostnames []dns.Domain // Additional allowed names in TLS certificate for DANE-TA.
daneVerifiedRecord *adns.TLSA // If non-nil, then will be set to verified DANE record if any.
remoteHostname dns.Domain // TLS with SNI and name verification.
daneRecords []adns.TLSA // For authenticating (START)TLS connection.
daneMoreHostnames []dns.Domain // Additional allowed names in TLS certificate for DANE-TA.
daneVerifiedRecord *adns.TLSA // If non-nil, then will be set to verified DANE record if any.
clientCert *tls.Certificate // If non-nil, tls client authentication is done.
// TLS connection success/failure are added. These are always non-nil, regardless
// of what was passed in opts. It lets us unconditionally dereference them.
@ -226,6 +227,9 @@ type Opts struct {
// If not nil, used instead of the system default roots for TLS PKIX verification.
RootCAs *x509.CertPool
// If set, the TLS client certificate authentication is done.
ClientCert *tls.Certificate
// TLS verification successes/failures is added to these TLS reporting results.
// Once the STARTTLS handshake is attempted, a successful/failed connection is
// tracked.
@ -281,6 +285,7 @@ func New(ctx context.Context, elog *slog.Logger, conn net.Conn, tlsMode TLSMode,
daneRecords: opts.DANERecords,
daneMoreHostnames: opts.DANEMoreHostnames,
daneVerifiedRecord: opts.DANEVerifiedRecord,
clientCert: opts.ClientCert,
lastlog: time.Now(),
cmds: []string{"(none)"},
recipientDomainResult: ensureResult(opts.RecipientDomainResult),
@ -417,12 +422,18 @@ func (c *Client) tlsConfig() *tls.Config {
return nil
}
var certs []tls.Certificate
if c.clientCert != nil {
certs = []tls.Certificate{*c.clientCert}
}
return &tls.Config{
ServerName: c.remoteHostname.ASCII, // For SNI.
// todo: possibly accept older TLS versions for TLSOpportunistic? or would our private key be at risk?
MinVersion: tls.VersionTLS12, // ../rfc/8996:31 ../rfc/8997:66
InsecureSkipVerify: true, // VerifyConnection below is called and will do all verification.
VerifyConnection: verifyConnection,
Certificates: certs,
}
}