Puncte:0

Apache nu folosește configurația directivei SSLProtocol și SSLCipherSuite

drapel ne

Încerc să configurez HTTPS pe serverul meu web. Am primit o eroare Cod de eroare: SSL_ERROR_NO_CYPHER_OVERLAP în firefox și ERR_SSL_VERSION_OR_CIPHER_MISMATCH în crom. L-am căutat și am descoperit că protocoalele sau cifrurile mele SSL nu sunt acceptate. Testează în ssllab (https://www.ssllabs.com/ssltest/) a dus laNu este acceptat niciun protocol securizat. Testul TLS de la GeekFlare (https://gf.dev/tls-test) spune că niciunul dintre protocoalele TLS nu este activat. Am testat si eu folosind nmap --script ssl-enum-ciphers -p 443 mydomain.com și obținerea acestui rezultat

Începând cu Nmap 7.91 ( https://nmap.org ) la 2021-11-09 11:23 WIB
Raport de scanare Nmap pentru mydomain.in-addr.arpa (mydomain)
Gazda este activă (latență de 0,0079 s).
SERVICIUL STATULUI PORTULUI
443/tcp deschide https
| ssl-enum-ciphers: 
| TLSv1.0: 
| cifruri: 
| TLS_DH_anon_WITH_AES_256_CBC_SHA - F
| compresoare: 
| NUL
| preferință de criptare: nedeterminată
| eroare de preferință de criptare: sunt acceptate prea puține cifruri
| Avertizări: 
| Forward Secrecy nu este acceptat de niciun cifr
| TLSv1.1: 
| cifruri: 
| TLS_DH_anon_WITH_AES_256_CBC_SHA - F
| compresoare: 
| NUL
| preferință de criptare: nedeterminată
| eroare de preferință de criptare: sunt acceptate prea puține cifruri
| Avertizări: 
| Forward Secrecy nu este acceptat de niciun cifr
| TLSv1.2: 
| cifruri: 
| TLS_DH_anon_WITH_AES_256_CBC_SHA - F
| compresoare: 
| NUL
| preferință de criptare: nedeterminată
| eroare de preferință de criptare: sunt acceptate prea puține cifruri
| Avertizări: 
| Forward Secrecy nu este acceptat de niciun cifr
|_ forță minimă: F

Nmap finalizat: 1 adresă IP (1 gazdă în sus) scanată în 2,67 secunde

Practic, niciunul dintre protocoalele și cifrurile pe care le-am pus în configurațiile ssl nu este folosit. Obțin același rezultat chiar și după ce am schimbat protocoalele și am încercat un cifru specific.

Folosesc Centos 8, Apache 2.4.37 și Openssl 1.1.1g

Aceasta este cea mai recentă setare a protocolului ssl și a cifrului meu:

SSLProtocol toate -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.3
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHACH384AECDS:-SHACH3840AEC:5POL -RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384

Le-am setat în toate configurațiile ssl pe care știu că conțin SSLProtocol și SSLCipherSuite pe serverul meu:

/etc/httpd/conf.d/ssl.conf

/etc/httpd/conf.d/mydomain.conf

/etc/letsencrypt/options-ssl-apache.conf

Editați | ×

cifruri openssl -s -v spectacole


TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=orice Au=orice Enc=AESGCM(256) Mac=AEAD
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=orice Au=orice Enc=CHACHA20/POLY1305(256) Mac=AEAD
TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=orice Au=orice Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-ECDSA-AES256-CCM TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM(256) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES128-CCM TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM(128) Mac=AEAD
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256
ECDHE-ECDSA-AES256-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1
ECDHE-RSA-AES256-SHA TLSv1 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1
ECDHE-ECDSA-AES128-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1
ECDHE-RSA-AES128-SHA TLSv1 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1
AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD
AES256-CCM TLSv1.2 Kx=RSA Au=RSA Enc=AESCCM(256) Mac=AEAD
AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD
AES128-CCM TLSv1.2 Kx=RSA Au=RSA Enc=AESCCM(128) Mac=AEAD
AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256
AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD
DHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=DH Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
DHE-RSA-AES256-CCM TLSv1.2 Kx=DH Au=RSA Enc=AESCCM(256) Mac=AEAD
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-CCM TLSv1.2 Kx=DH Au=RSA Enc=AESCCM(128) Mac=AEAD
DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256
DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1

openssl s_client -connect server_public_IP:443 se intoarce

CONECTAT(00000003)
140639468660544:error:14094410:SSL rutine:ssl3_read_bytes:sslv3 alert handshake failure:ssl/record/rec_layer_s3.c:1544:SSL alert number 40
---
nu este disponibil niciun certificat de egalitate
---
Nu s-au trimis nume de CA de certificat de client
---
SSL handshake a citit 7 octeți și a scris 301 octeți
Verificare: OK
---
Nou, (NONE), Cipher este (NIMIC)
Renegocierea sigură NU ESTE acceptată
Compresie: NIMIC
Extindere: NIMIC
Nu s-a negociat ALPN
Datele timpurii nu au fost trimise
Verificați codul de returnare: 0 (ok)
---

Am încercat de multe ori alt protocol și criptare TLS și fiecare schimbare pe care am făcut-o nu a făcut nimic.

Este ceva ce mi-a scapat?

Poate că există un alt fișier de configurare care suprascrie configurația?

Orice ajutor este apreciat, multumesc

drapel br
Aveți o secțiune `ssl_conf` în fișierul de configurare openssl la nivel de sistem (`/etc/pki/tls/openssl.cnf` pe CentOS cred). Dacă da, asta poate limita alegerea dvs. de cifruri. De asemenea, `openssl -s -v` listează toate/unele/una dintre suitele de criptare alese de dvs.?
actomobile avatar
drapel ne
@garethTheRed acesta este ssl_conf în interiorul openssl.cnf ```ssl_conf = ssl_module```. ce ar trebui sa schimb pentru a o repara? ```openssl ciphers -s -v``` are într-adevăr suitele de criptare alese de mine
drapel br
Comentați-l temporar și vedeți dacă vă ajută. De asemenea, `openssl ciphers -s -v` trebuie să listeze cifrurile care sunt acceptabile pentru serverul dvs. __și__ oferite de client - nu doar cele dintâi.
actomobile avatar
drapel ne
@garethTheRed Comentarea nu a ajutat. Aceleași rezultate. Aceste cifruri sunt de la generatorul de configurare ssl al Mozilla, presupun că ar trebui să le accepte. De asemenea, există linia ```.include /etc/crypto-policies/back-ends/opensslcnf.config``` în ```openssl.cnf```. acel fișier are și secțiunea CipherSuite. Poate că și asta suprascrie configurația?
actomobile avatar
drapel ne
Nu, schimbarea CipherSuites în ```/etc/crypto-policies/back-ends/opensslcnf.config``` nu a funcționat
drapel br
Puteți începe să utilizați Wireshark sau tcpdump pentru a monitoriza serverul și a vedea ce cifruri sunt oferite în timpul strângerii de mână. O altă opțiune este să folosiți clienți diferiți (de exemplu, `openssl s_client`) pentru a vedea dacă se conectează și chiar să încercați un server de bază cu `openssl s_server` pentru a vedea dacă acesta permite conexiuni. Aceste instrumente ar trebui să vă ajute să restrângeți unde se află problema.
actomobile avatar
drapel ne
@garethTheRed `openssl s_server` returnează diverse erori despre un fișier de certificat care nu există. După generarea acestor fișiere, eroarea fișierelor lipsă nu a apărut, în schimb am primit `140638281008960:error:0909006C:PEM routines:get_name:no start line:crypto/pem/pem_lib.c:745:Expecting: ANY PRIVATE KEY`. dar nu știu ce fișier ar trebui să aibă linia PRIVATE KEY
drapel br
Dacă te uiți la pagina de manual pentru s_server, vei vedea că are nevoie de o cheie privată. Acesta poate fi fie încorporat în certificat (transmis ca `-cert`), fie un fișier diferit transmis ca `-key`. Cheia privată va fi creată când ați generat certificatul.
actomobile avatar
drapel ne
@garethTheRed adăugând `-cert` și `-key` funcționează. Comanda returnează `Utilizarea parametrilor DH temp impliciti ACCEPT`. Presupun că motivul pentru care nmap arată doar cifrul `TLS_DH_anon_WITH_AES_256_CBC_SHA - F` este pentru că openssl folosește parametrii DH? Dacă da, cum pot schimba asta?
drapel br
Dacă îl rulați din nou cu opțiunea `-www` (minuscule), apoi îndreptați un browser către el, acesta va lista cifrurile de care este capabil și cifrurile comune pentru acesta și browser. Asta te poate ajuta. De asemenea, care este algoritmul cheii publice? Lista din întrebarea dvs. are doar RSA și ECDSA ca algoritmi cheie acceptabili - presupun că utilizați unul dintre aceștia?
actomobile avatar
drapel ne
@garethTheRed Folosesc RSA ca algoritm cheie (cred). Mă gândesc că poate problema se află în rețeaua exterioară? Utilizarea IP localhost atunci când rulați `nmap` sau `s_client` în cadrul serverului funcționează bine și cifrurile sunt listate. Dar când folosesc IP-ul public al serverului, rezultatele sunt aceleași cu erorile de mai sus.
actomobile avatar
drapel ne
Dacă opresc serviciul httpd, am o eroare diferită când am încercat să accesez web folosind http și https. http returnează „Conexiunea a fost resetată” în timp ce https returnează în continuare același „NO_CYPHER_OVERLAP”. nu ar trebui sa aiba aceeasi eroare?
drapel br
Apoi mai rulează ceva care răspunde. Rulați `netstat -tlnp` sau `ss -tlnp` (ambele ca root) pentru a vedea ce ascultă pe acele porturi.
actomobile avatar
drapel ne
@garethTheRed Acesta pare să fie cazul. Dar numai httpd ascultă portul. Când îl opresc, verificatorul de porturi deschise arată că portul este încă deschis, deși nimic nu ascultă portul. Poate că problema este într-adevăr în afara serverului meu.
actomobile avatar
drapel ne
@garethTheRed Am găsit problema! Se pare că pur și simplu portul nu este redirecționat și altceva îl ascultă într-adevăr. Nu m-am gândit niciodată la asta de când a fost deschis în verificatorul de porturi deschise, așa că am crezut că a fost deja redirecționat. Multumesc pentru ajutor!
Puncte:1
drapel ne

Se pare că problema nu este în configurație. Portul pe care îl folosesc pur și simplu nu este redirecționat și altceva îl ascultă, astfel încât verificatorul de porturi deschis să arate portul ca deschis. Totul funcționează bine după redirecționarea portului

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.