TLS, y certificados de ACME

Desde la v0.9.0, WebDAV y S3 se sirven por HTTPS, y NFS sobre RPC-with-TLS (RFC 9289), con tls = true en su bloque serve y un bloque tls que indica de dónde procede el certificado.

A partir de archivos

tls {
  cert_file = "/etc/fileshare/tls/fullchain.pem"
  key_file  = "/etc/fileshare/tls/key.pem"
}

serve "webdav" {
  addr = "0.0.0.0:443"
  tls  = true
}

Los archivos se recargan cuando cambian, así que una renovación escrita por otra herramienta se aplica sin reiniciar. El certificado lo gestiona go-authn/servercert.

A partir de una CA ACME

Let’s Encrypt por defecto; o una CA que le conoce mediante vinculación de cuenta externa (external account binding, EAB), como GÉANT TCS a través de HARICA:

tls {
  acme {
    directory_url     = "https://acme-v02.harica.gr/acme/<uuid>/directory"   # the Server URL cm.harica.gr shows
    domains           = ["files.example.org"]
    cache_dir         = "/var/lib/fileshare/acme"
    eab_key_id        = "…"
    eab_hmac_key_file = "/etc/fileshare/tls/eab.key"   # a secret: a file, never the config
  }
}

Que ACME pueda funcionar depende de cómo comprueba la CA el nombre

La última fila es la que importa para un servidor de archivos dentro de una red de campus: con una cuenta GÉANT TCS cuyo dominio la institución ya ha validado en HARICA, no hay que abrir ningún puerto a Internet.

HARICA (GÉANT TCS): qué cuenta, y CAA

Las cuentas ACME de HARICA son de dos clases, y solo una prescinde del desafío:

• una cuenta Enterprise Admin emite certificados OV para los dominios que la institución ha validado: ningún desafío — es la que necesita un servidor que nadie de fuera puede alcanzar;
• una cuenta Enterprise User emite certificados DV, y DV significa que la CA comprueba el nombre en cada pedido, con tls-alpn-01 o http-01 como arriba.

En ambos casos, el registro CAA del dominio, si lo tiene, debe autorizar harica.gr, o el pedido se rechaza.

Cuándo se pide el certificado

Al arrancar (desde la v0.27.0): una vez abiertos los puertos, se obtiene el certificado de cada dominio configurado, o se relee del directorio de caché. Un fallo no detiene el servidor — sigue sirviendo y lo reintenta tras 1 minuto, duplicando hasta 1 hora — y la primera conexión TLS que nombra el host lo pide de nuevo en cualquier caso. Se renueva 30 días antes de caducar, o en el último tercio de su vida cuando eso es antes.

Un cliente que no envía SNI — uno que se conecta por dirección IP — recibe el certificado del primer dominio (desde la v0.27.0); antes, el saludo fallaba. El cliente sigue comprobando ese certificado contra la dirección que marcó: ayuda a un cliente al que se le dijo que confiara en ese nombre, y no engaña a nadie.

WebDAV no se sirve sin cifrar

webdav on 0.0.0.0:8080 would carry passwords in the clear: serve it with
tls = true, or -- when TLS is terminated in front of it, by a proxy -- say
plaintext = true

Una configuración que arrancaba antes de la v0.9.0 con serve "webdav" { addr = "0.0.0.0:8080" } no arranca después. Dos salidas:

serve "webdav" {
  addr = "0.0.0.0:443"
  tls  = true            # with a tls block
}

o, cuando un proxy inverso termina TLS delante y reenvía sin cifrar:

serve "webdav" {
  addr      = "10.0.0.5:8080"
  plaintext = true       # TLS is terminated in front of this, on purpose
}

Las direcciones de loopback (127.0.0.1, ::1, localhost) y un servidor sin nadie a quien autenticar —sin user, sin users, sin bloque oidc— no se ven afectados. Un bloque serve sin addr queda en loopback, y tampoco se ve afectado.

plaintext es solo para WebDAV, el protocolo que envía una contraseña, y plaintext junto con tls se rechaza: uno u otro.

Lo que dice check

fileshare check imprime, por protocolo, lo que está cifrado y lo que va sin cifrar a propósito:

webdav: TLS, certificate from the files /etc/fileshare/tls/fullchain.pem and /etc/fileshare/tls/key.pem
nfs: TLS, certificate from the files /etc/fileshare/tls/fullchain.pem and /etc/fileshare/tls/key.pem; clients present one signed by /etc/fileshare/tls/clients.pem (the machine, not the person)

y, para WebDAV detrás de un proxy,

webdav: in the clear on 10.0.0.5:8080, on purpose (plaintext = true): TLS must be terminated in front of it

Por protocolo

NFS sobre TLS prueba la máquina, no la persona

serve "nfs" {
  tls            = true
  client_ca_file = "/etc/fileshare/tls/clients.pem"
}

client_ca_file obliga al cliente a presentar un certificado de esa autoridad —qué máquina está montando—, y el RFC 9289 deja la autenticación de usuarios como estaba: el uid de dentro sigue siendo el que afirma AUTH_SYS. Así que un recurso compartido que nombra quién puede usarlo sigue rechazándose por NFS sin un bloque kerberos, o sin identidades a partir de certificados, que son un uso distinto del mismo certificado.

TLS se ofrece, no se exige: a un cliente que nunca lo pide se le siguen sirviendo los recursos compartidos abiertos. client_ca_file sin tls = true se rechaza —no comprobaría nada—, y client_ca_file en cualquier protocolo distinto de NFS también se rechaza.

Qué más se rechaza

• tls = true sin bloque tls: nada indica de dónde procede el certificado.
• Un bloque tls que ningún bloque serve usa: nada lo usaría.
• Un http_challenge que no es una dirección en la que escuchar.