This page is intended as a guidance to configure flnews for TLS connections and to understand how they work.
The first property of a secure connection is encryption. TLS always use symmetric encryption for the payload. This means both ends of the connection need to share the same secret key.
The key exchange for the symmetric encryption of the payload can be
done on the fly (on both sides without transmitting it over the
connection at all) using the
Diffie-Hellman-Merkle
algorithm. If the generated keys are deleted on both sides after the
connection was closed,
Forward secrecy
is provided.
Note that you have to trust the server operator that he really delete
his copy of the key for this to work.
flnews always use this algorithm (called DHE) as long as the user
doesn't configured the "weak" mode in the server configuration
GUI.
The negotiation of the DHE group is possible for the TLSv1.2 and
TLSv1.3 protocols with the
Supported Groups
extension. flnews has partial support for this negotiation with
OpenSSL 1.1 and full support with OpenSSL 3.
To guarantee integrity of the transmitted payload, a
MAC
algorithm is used. This prevents that foreign encrypted data can be
injected into the payload. Depending on the mode used for the symmetric
cipher, this part may already be included (e.g. for AES in GCM mode).
This is called
AEAD.
If AEAD is supported by the used OpenSSL library and at least the
TLSv1.2 protocol is supported by the server, such modes are preferred
by flnews and offered on top of the list for negotiation.
The second property of a secure connection is to verify that the
communication partner really is the one you have contacted (and vice
versa). If authentication fails, somebody ("man in the
middle") can intercept the connection and read the encrypted data
by faking the identity of you and/or the server operator to the other
side respectively.
For a TLS connection to a USENET server different algorithms are used
for each direction in most cases.
The server authenticates to you via a chain of
X.509
certificates. For this to work you have to trust the root certificate
of the chain - this means the person or
CA
that signed it.
In the trivial case, the chain consists of only the root certificate
from the server operator himself. Such a certificate is called
"self signed" and you have to trust the server operator
directly (that he is the person you expect and that he can protect the
private part of the signing key from abuse).
In the case of a longer certificate chain, every following certificate
is signed with the former one and you have to trust the anchor
of the chain (the Certificate Authority "CA" that issued the
root certificate).
Your trust inherits to the intermediate and server certificates (you
trust the anchor, the signature from the anchor in the first linked
certificate ensures that you can trust this certificate too, and so
on).
To trust a root certificate, you have to install it on your computer so
that the OpenSSL library can find it. For a "self signed"
server certificate you normally have to do this manually.
For the well known CAs, the vendor of your operating system often
install their root certificates automatically.
Note: The servers certificate (in human readable form) from the current (or last repectively, after flnews was terminated) connection can be found in ~/.config/flnews/logfile.
You authenticate against the server not at all (anonymous access) or via AUTHINFO USER/PASS extension from RFC4643. Because this authentication transmits login and password as plain text, it depends on the encrypted TLS connection (that is established first by flnews, unless you explicitly disabled this behaviour with the option CFG_NNTP_AUTH_UNENCRYPTED at compile time).
Note: Other algorithms like SASL or X.509 are currently not implemented for client authentication.
The server configuration GUI of flnews allow you to select between three TLS option:
If TLS is disabled, client to server authentication is not possible
with flnews (unless you explicitly enabled this behaviour with the
option CFG_NNTP_AUTH_UNENCRYPTED at compile time).
If your server requires authentication, first try to enable the strong
encryption mode. Use the compatibility mode only if it doesn't work.
If you use flnews out of the box, an opportunistic approach is used for server to client authentication (that should work in most cases without any knowledge).
If your server use a certificate chain for which your OpenSSL installation already contain a matching root certificate, you should be able to connect but get the following warning:
flnews: TLS: Warning: X.509 certificate revocation checks disabled [...] flnews: TLS: Server certificate verification successful (revocation checks were skipped)
This should be sufficient for fast expiring certificates like the ones from the Let's Encrypt CA.
For certificates with expiration periods of one or more years, the user should check whether the certificate was revoked in the meantime. Otherwise, if a certificate in the chain was revoked by its issuer, it is nevertheless accepted. If you want to enable revocation checks, read the next section.
This example if usable e.g. for the provider
Individual.NET.
In general it should work for certificates that contain
X.509v3 CRL Distribution Points entries with URIs that can be
accessed with the HTTP protocol.
Every CA that issues certificates should provide a list that contains all the revoked certificates (that should no longer be accepted). flnews can download and use such CRLs to reject all certificate chains that contain revoked elements.
Open the file CONFIG in the flnews source tree and define the following option as specified:
CFG_TLS_CRLS_DISABLE=0
This option is set to 1 (disabled) by default because the CRL check code increases the documented system requirements (to POSIX.1-2001 or XSI extension).
After being recompiled, flnews can now search (for every certificate in the chain) the CRL distribution point and download the CRL (into the directory ~/.config/flnews/crls/) and use its content for the revokation checks.
The steps above provide the infrastructure for the CRL checks (that are
still disabled by default now).
To enable CRL checks open the file ~/.config/flnews/configfile
and define the following option as specified:
crl_check: 1
After starting flnews you should now see something like this on the terminal:
flnews: TLS: OpenSSL library version: 1.1.1 (0x1010100F) flnews: TLS: Protocol version TLSv1.3 available for negotiation [...] flnews: TLS: Location of X.509 CRLs: ~/.config/flnews/crls/ flnews: TLS: Using SNI extension with: news.individual.de flnews: TLS: Using protocol: TLSv1.2 with cipher suite DHE-RSA-AES256-GCM-SHA384 flnews: TLS: Peer signature algorithm: RSASSA-PKCS1-v1_5+SHA512 flnews: TLS: FFDHE group size: 2048 bit flnews: TLS: Warning: FFDHE group size should be at least 3072 bit flnews: TLS: ----------------------------------------------------- flnews: TLS: Automatic CRL maintenance flnews: TLS: Server certificate: flnews: TLS: Issuer: C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA flnews: TLS: CRL distribution point 0: http://cdp1.pca.dfn.de/dfn-ca-global-g2/pub/crl/cacrl.crl flnews: EXT: File download delegation to /home/micha/.config/flnews/crls/CRL0 for: http://cdp1.pca.dfn.de/dfn-ca-global-g2/pub/crl/cacrl.crl flnews: INET: Using IPv4 protocol flnews: HTTP: File successfully downloaded flnews: TLS: Intermediate certificate: flnews: TLS: Issuer: C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. V., OU = DFN-PKI, CN = DFN-Verein Certification Authority 2 flnews: TLS: CRL distribution point 0: http://cdp1.pca.dfn.de/global-root-g2-ca/pub/crl/cacrl.crl flnews: EXT: File download delegation to /home/micha/.config/flnews/crls/CRL1 for: http://cdp1.pca.dfn.de/global-root-g2-ca/pub/crl/cacrl.crl flnews: INET: Using IPv4 protocol flnews: HTTP: File successfully downloaded flnews: TLS: Intermediate certificate: flnews: TLS: Issuer: C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust Center, CN = T-TeleSec GlobalRoot Class 2 flnews: TLS: CRL distribution point 0: http://pki0336.telesec.de/rl/TeleSec_GlobalRoot_Class_2.crl flnews: EXT: File download delegation to /home/micha/.config/flnews/crls/CRL2 for: http://pki0336.telesec.de/rl/TeleSec_GlobalRoot_Class_2.crl flnews: INET: Using IPv4 protocol flnews: HTTP: File successfully downloaded flnews: TLS: Root certificate: flnews: TLS: Issuer: C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust Center, CN = T-TeleSec GlobalRoot Class 2 flnews: TLS: Always trusted if installed (Must be uninstalled for revocation) flnews: TLS: ----------------------------------------------------- flnews: TLS: Verification of certificate aborted because of CRL update flnews: NNTP: TLS module has requested to close the connection flnews: CORE: Lost nexus, trying to recover [...] flnews: TLS: Location of X.509 CRLs: ~/.config/flnews/crls/ flnews: TLS: Using SNI extension with: news.individual.de flnews: TLS: Using protocol: TLSv1.2 with cipher suite DHE-RSA-AES256-GCM-SHA384 flnews: TLS: Peer signature algorithm: RSASSA-PKCS1-v1_5+SHA512 flnews: TLS: FFDHE group size: 2048 bit flnews: TLS: Warning: FFDHE group size should be at least 3072 bit flnews: TLS: Certificate level 0 (Server) in chain: flnews: TLS: RSA key modulus size: 2048 bit flnews: TLS: Warning: RSA key modulus should be at least 3072 bit flnews: TLS: Key fingerprint is SHA256:/InplDY2MR82nVE8jErYdVpBXlBYEGarMN4s1ncvQdQ= flnews: TLS: +-----------------+ flnews: TLS: | o ..+E | flnews: TLS: | . o .o+ | flnews: TLS: | . .. . | flnews: TLS: | . .. o | flnews: TLS: | S + o | flnews: TLS: | X + | flnews: TLS: | X + | flnews: TLS: | = o | flnews: TLS: | . | flnews: TLS: +-----------------+ flnews: TLS: Signature algorithm: RSA-SHA256 flnews: TLS: Certificate level 1 in chain: flnews: TLS: RSA key modulus size: 2048 bit flnews: TLS: Warning: RSA key modulus should be at least 3072 bit flnews: TLS: Signature algorithm: RSA-SHA256 flnews: TLS: Certificate level 2 in chain: flnews: TLS: RSA key modulus size: 2048 bit flnews: TLS: Warning: RSA key modulus should be at least 3072 bit flnews: TLS: Signature algorithm: RSA-SHA256 flnews: TLS: Certificate level 3 (Root) in chain: flnews: TLS: RSA key modulus size: 2048 bit flnews: TLS: Warning: RSA key modulus should be at least 3072 bit flnews: TLS: Self signature is not used flnews: TLS: Server certificate: flnews: TLS: Subject Alternative Name: news.individual.de (matches hostname) flnews: TLS: Server certificate verification successful
Note: The warnings above indicate that flnews considers the FFDHE group used for the key exchange and the RSA keys used for signatures in the certificate chain as weaker than it's threshold level (that is set to values that more or less matches the AES128 symmetric cipher according to the NIST).
flnews will update the CRLs in regular intervals that defaults to 20
hours.
Note: The check whether the CRL update interval is elapsed is done only
once at startup.
CRLs can be big. If you encounter problems with long download times, open the file ~/.config/flnews/configfile and define the following option as specified:
crl_upd_c: 1
This will create a popup dialog that allows you to skip the CRL updates for the current session.
This example was created for the (now defunct) provider
Albasani.
In general this works for root certificates of CAs too.
If you don't want to add the self signed (or CA root) certificate to your global OpenSSL configuration (or you can't do this because you don't have root permission on the system) open the file ~/.config/flnews/configfile and define the following option as specified:
tls_owncerts: 1
flnews will now search root certificates in the directory ~/.config/flnews/certs/ when a certificate chain must be verified.
Now you need to manually install the certificate into this directory. If you can't get the certificate directly, you can extract it from a connection request with the OpenSSL command line utility like this:
$ openssl s_client -showcerts -connect reader.albasani.net:563
In the Certificate chain section you should see a single entry
and the certificate in PEM format (in the case of a certificate chain,
look for the last certificate).
It must look like this:
-----BEGIN CERTIFICATE----- [Base64 encoded data] -----END CERTIFICATE-----
Create a file with arbitrary name in the directory described above and copy the certificate block into it.
Now use the OpenSSL command line tool c_rehash to create a symbolic link that OpenSSL can use to find the certificate:
$ cd ~/.config/flnews/certs/ $ c_rehash . $ ls -l total 4 -rw-r--r-- 1 baeuerle users 1383 Mar 5 13:36 albasani.pem lrwxrwxrwx 1 baeuerle users 12 Mar 5 13:36 f7865808.0 -> albasani.pem
After starting flnews you should now see something like this on the terminal:
flnews: TLS: OpenSSL library version: 1.1.1 (0x1010100F) flnews: TLS: Protocol version TLSv1.3 available for negotiation [...] flnews: TLS: Location of X.509 root certificates: ~/.config/flnews/certs/ flnews: TLS: Warning: X.509 certificate revocation checks disabled in configfile flnews: TLS: Using SNI extension with: reader.albasani.net flnews: TLS: Using protocol: TLSv1 with cipher suite DHE-RSA-AES256-SHA flnews: TLS: Peer signature algorithm: RSASSA-PKCS1-v1_5+MD5-SHA1 flnews: TLS: FFDHE group size: 1024 bit flnews: TLS: Warning: FFDHE group size should be at least 3072 bit flnews: TLS: Certificate level 0 (Root) in chain: flnews: TLS: RSA key modulus size: 1024 bit flnews: TLS: Warning: RSA key modulus should be at least 3072 bit flnews: TLS: Key fingerprint is SHA256:mToFDVshgIypfdCU5v77E/eIGvoH3UIDYOR7NJ/t4MM= flnews: TLS: +-----------------+ flnews: TLS: | + +ooo o. | flnews: TLS: |o + + * | flnews: TLS: |.. + o . | flnews: TLS: |. . o . o | flnews: TLS: | o S | flnews: TLS: | . oE | flnews: TLS: | .o . | flnews: TLS: | ... | flnews: TLS: | .o.. | flnews: TLS: +-----------------+ flnews: TLS: Self signature is not used flnews: TLS: Server certificate verification successful (revocation checks were skipped)
Note: The warning about the FFDHE group used for the key exchange indicate that flnews considers it as weaker than it's threshold level (that is set to values that more or less matches the AES128 symmetric cipher according to the NIST).
The warning about the disabled certificate revocation check can be
ignored for a single self-signed certificate (because there is only
this single, explicitly trusted root certificate).
For a CA root certificate (with a chain of further certificates on
top), read the information about CRLs above.
Last update: 2022-01-03
michael.baeuerle@gmx.net.