Configuring flnews for TLS connections







General

This page is intended as a guidance to configure flnews for TLS connections and to understand how they work.


Encryption

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 via asymmetric encryption or the key can be generated 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, the latter option provides Forward secrecy (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 the latter algorithm (and doesn't offer asymetric encryption to the server) as long as the user doesn't configured the "weak" mode in the server configuration GUI.

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 the TLSv1.2 protocol is supported by the server, such modes are preferred by flnews and offered on top of the list for negotiation.


Authentication

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 the server operator to the other side respectively.
For a TLS connection to a USENET server different algorithms are used for each direction.

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 that is signed by 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 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 CA that signed the root certificate). Your trust inherits to the intermediate certificates (you trust the anchor, the anchor trust the first link, 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" 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.

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 always established first by flnews).




Strong and weak mode

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 (because methods like SASL are currently not supported).
If your server requires authentication, first try to enable the strong encryption mode. Use the compatibility mode only if it doesn't work.




Certificate chain

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 is better than nothing, but if a certificate in the chain was revoked by its issuer, it is nevertheless accepted. If you want to do it right, read the next section.




Certificate chain with CRL checks [EXPERIMENTAL]

This example if usable e.g. for the provider Individual.NET.

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 src/tls.c in the flnews source tree and define the following constants as specified:

#define CFG_USE_TLS_CRLS      1
#define CFG_USE_TLS_OWNCERTS  0

After being recompiled, flnews will now search (for every certificate in the chain) the CRL distribution point and download the CRL into the following directory:

~/.flnews/crls/

and use its content for the revokation checks.

After starting flnews you should now see something like this on the terminal:

flnews: TLS: OpenSSL library version: 1.0.0r (0x1000012F)
flnews: TLS: Location of X.509 CRLs: ~/.flnews/crls/
flnews: TLS: Using protocol: TLSv1 with cipher suite DHE-RSA-AES256-SHA
flnews: TLS: Warning: DH parameter check not possible with OpenSSL API 1.0
flnews: TLS: -----------------------------------------------------
flnews: TLS: Automatic CRL maintenance (EXPERIMENTAL)
flnews: TLS: Server certificate:
flnews: TLS:    Issuer: C = DE, ST = Berlin, L = Berlin, O = Freie Universitaet Berlin, OU = ZEDAT, CN = Freie Universitaet Berlin - FU-CA - G01, emailAddress = ca@FU-Berlin.DE
flnews: TLS:    CRL distribution point 0: http://cdp1.pca.dfn.de/fu-ca/pub/crl/cacrl.crl
flnews: EXT: File download delegation to ~/.flnews/crls/CRL0 for: http://cdp1.pca.dfn.de/fu-ca/pub/crl/cacrl.crl
flnews: HTTP: File successfully downloaded
flnews: TLS: Intermediate certificate:
flnews: TLS:    Issuer: C = DE, O = DFN-Verein, OU = DFN-PKI, CN = DFN-Verein PCA Global - G01
flnews: TLS:    CRL distribution point 0: http://cdp1.pca.dfn.de/global-root-ca/pub/crl/cacrl.crl
flnews: EXT: File download delegation to ~/.flnews/crls/CRL1 for: http://cdp1.pca.dfn.de/global-root-ca/pub/crl/cacrl.crl
flnews: HTTP: File successfully downloaded
flnews: TLS: Intermediate certificate:
flnews: TLS:    Issuer: C = DE, O = Deutsche Telekom AG, OU = T-TeleSec Trust Center, CN = Deutsche Telekom Root CA 2
flnews: TLS:    CRL distribution point 0: http://pki0336.telesec.de/rl/DT_ROOT_CA_2.crl
flnews: EXT: File download delegation to ~/.flnews/crls/CRL2 for: http://pki0336.telesec.de/rl/DT_ROOT_CA_2.crl
flnews: HTTP: File successfully downloaded
flnews: TLS: Root certificate:
flnews: TLS:    Issuer: C = DE, O = Deutsche Telekom AG, OU = T-TeleSec Trust Center, CN = Deutsche Telekom Root CA 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: ~/.flnews/crls/
flnews: TLS: Using protocol: TLSv1 with cipher suite DHE-RSA-AES256-SHA
flnews: TLS: Warning: DH parameter check not possible with OpenSSL API 1.0
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:    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: individual.de (doesn't match hostname)
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 RSA keys used for the 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 (can be configured with the option crl_upd_iv in the configfile).
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, try to set the option crl_upd_c in the configfile to 1. This creates a popup dialog that allows you to skip the CRL updates for the current session.




Single, self signed certificate

This example if usable e.g. for the provider Albasani.

If you don't want to add the self signed 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 src/tls.c in the flnews source tree and define the following constants as specified:

#define CFG_USE_TLS_CRLS      0
#define CFG_USE_TLS_OWNCERTS  1

After being recompiled, flnews will now search root certificates in the directory:

~/.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 tools like this:

$ openssl s_client -showcerts -host reader.albasani.net -port 563

In the Certificate chain section you should see a single entry and the certificate in PEM format. It looks 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 ~/.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 this on the terminal:

flnews: TLS: Location of X.509 root certificates for verify: ~/.flnews/certs/
flnews: TLS: Warning: X.509 certificate revocation checks disabled
flnews: TLS: OpenSSL library version: 1.0.1k (0x100010BF)
flnews: TLS: Using protocol: TLSv1 with cipher suite DHE-RSA-AES256-SHA
flnews: TLS: Server certificate:
flnews: TLS:    Subject: C = CH, ST = Some-State, L = Zurich, O = Albasani, OU = Roman Racine, CN = reader.albasani.net, emailAddress = roman.racine@gmail.com
flnews: TLS: Server certificate verification successful (revocation checks were skipped)

If it doesn't work, verify that you connect to the hostname that is listed in the CN field of the certificate.

The warning about the disabled certificate revocation check can be ignored in this case (because there is only the single, explicitly trusted root certificate).




Browser        IDFC        Last update: 2016-12-11        michael.baeuerle@gmx.net.