No shared cipher

Goedeavond,

Sinds enkele jaren draaien we een VPS met verschillende websites erop. Tot voor kort hadden we nooit problemen met de handtekening tussen beide servers.

Recentelijk hebben we echter een klant die niet naar ons kan mailen. De klant krijgt na verloop van tijd een mail terug met een foutmelding.

De logs tonen het volgende aan:

2023-07-12 19:37:35 TLS error on connection from ***** [*****] (SSL_accept): error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher

Onze ciphers zijn als volgt:

Cipher Suites

# TLS 1.3 (suites in server-preferred order)
TLS_AES_256_GCM_SHA384 (0x1302)   ECDH x25519 (eq. 3072 bits RSA)   FS    256
TLS_CHACHA20_POLY1305_SHA256 (0x1303)   ECDH x25519 (eq. 3072 bits RSA)   FS    256
TLS_AES_128_GCM_SHA256 (0x1301)   ECDH x25519 (eq. 3072 bits RSA)   FS    128
TLS_AES_128_CCM_SHA256 (0x1304)   ECDH x25519 (eq. 3072 bits RSA)   FS    128
# TLS 1.2 (suites in server-preferred order)
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)   ECDH x25519 (eq. 3072 bits RSA)   FS    128
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)   ECDH x25519 (eq. 3072 bits RSA)   FS    256
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)   ECDH x25519 (eq. 3072 bits RSA)   FS    256

De tegenpartij gebruikt de volgende ciphers:

Cipher Suites
# TLS 1.2 (suites in server-preferred order)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)   ECDH secp256r1 (eq. 3072 bits RSA)   FS    128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)   ECDH secp256r1 (eq. 3072 bits RSA)   FS   WEAK    128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   ECDH secp256r1 (eq. 3072 bits RSA)   FS   WEAK    128
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d)   WEAK    256
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c)   WEAK    128
TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d)   WEAK    256
TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c)   WEAK    128
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)   WEAK    256
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)   WEAK    128
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)   WEAK    112

Zoals u kunt zien, hebben we geen gemeenschappelijke cipher. Het is momenteel voor de tegenpartij niet mogelijk om dit probleem op te lossen.

Hoe kunnen we een cipher toevoegen/activeren? We hebben al enkele aanpassingen geprobeerd in Exim zonder succes.

Kan iemand ons hiermee op weg helpen? Alvast bedankt voor uw hulp!

Beste Ferhat,

Ik wil graag uw aandacht vestigen op enkele aanpassingen die we hebben aangebracht in het exim.variables.conf.custom bestand voor Exim.conf:

tls_require_ciphers = ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
openssl_options = +no_sslv2 +no_sslv3

Na het uitvoeren van de opdracht om Exim opnieuw te starten en de server te herstarten, blijft het probleem echter bestaan.

Heeft u mogelijk nog suggesties om deze kwestie aan te pakken?

Ook heb ik het volgende commando gebruikt om een analyse uit te voeren:

 nmap --script ssl-enum-ciphers --script-args vulns.showall -p 465 127.0.0.1

Hier zijn de resultaten van de analyse:

Starting Nmap 7.70 ( https://nmap.org ) at 2023-08-10 08:15 CEST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000054s latency).

PORT    STATE SERVICE
465/tcp open  smtps
| ssl-enum-ciphers: 
|   TLSv1.2: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (secp256r1) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 4096) - C
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 4096) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 4096) - A
|     compressors: 
|       NULL
|     cipher preference: client
|     warnings: 
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|       Key exchange (secp256r1) of lower strength than certificate key
|_  least strength: C

Nmap done: 1 IP address (1 host up) scanned in 0.67 seconds

Ik kijk uit naar uw aanvullende suggesties.

Citaat van Ferhat.Remory

Bedankt voor de aanvullende informatie. Laten we dit stap voor stap aanpakken.

1. Cipher Overeenkomst: Uit de informatie die u heeft verstrekt, blijkt dat uw server nu de cipher TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ondersteunt, wat overeenkomt met een van de ciphers die de tegenpartij gebruikt. Dit zou in theorie moeten betekenen dat er een gemeenschappelijke cipher is voor communicatie.
2. Cipher Volgorde: Het kan zijn dat, hoewel de ciphers overeenkomen, de volgorde waarin ze worden aangeboden of geprefereerd door de server/client een probleem veroorzaakt. De cipher volgorde kan van invloed zijn op welke cipher daadwerkelijk wordt gekozen voor de verbinding.
3. Waarschuwingen in Nmap Resultaten: De waarschuwingen die worden getoond in uw Nmap-resultaten zijn belangrijk. De waarschuwing over de SWEET32-aanval betekent dat de 3DES-cipher kwetsbaar is en idealiter zou moeten worden uitgeschakeld. De tweede waarschuwing geeft aan dat de sleuteluitwisseling van lagere sterkte is dan de certificaatsleutel. Dit kan een probleem zijn, afhankelijk van de configuratie van de tegenpartij.

Suggesties:

1. Cipher Volgorde Aanpassen: Probeer de volgorde van de ciphers in tls_require_ciphers aan te passen zodat TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 bovenaan staat, gevolgd door andere ciphers die overeenkomen met de tegenpartij.
2. 3DES Uitschakelen: Overweeg het uitschakelen van de 3DES-cipher om de SWEET32 kwetsbaarheid te vermijden. Dit kan gedaan worden door DES-CBC3-SHA te verwijderen uit de tls_require_ciphers lijst.
3. Certificaat en Sleuteluitwisseling: Controleer of uw servercertificaat en de sleuteluitwisselingsmethode compatibel zijn. Als u bijvoorbeeld een ECDSA-certificaat gebruikt, maar de tegenpartij ondersteunt alleen RSA, dan kan dat een probleem zijn.
4. Logbestanden: Blijf de Exim-logbestanden controleren op aanvullende foutmeldingen of waarschuwingen die kunnen helpen bij het diagnosticeren van het probleem.
5. Testen: Gebruik tools zoals openssl s_client om een TLS-handshake met uw server te simuleren en te zien welke fouten of waarschuwingen worden weergegeven. Dit kan aanvullende inzichten bieden.

Commando voorbeeld:

Code

openssl s_client -connect uw_server_adres:465 -cipher ECDHE-RSA-AES128-GCM-SHA256

1. Overweeg een Tijdelijke Oplossing: Als een snelle oplossing nodig is en de tegenpartij hun configuratie niet kan wijzigen, overweeg dan om tijdelijk een additionele cipher toe te voegen die zij ondersteunen, zelfs als deze als "zwak" wordt beschouwd. Zorg er echter voor dat u dit later corrigeert om de beveiliging te waarborgen.

Dat antwoord is vrijwel identiek (met enkele kleine aanpassingen) aan dat van ChatGPT

Ik verzoek de andere partij om een testmail te sturen.