Már-már attól tartok, hogy el kell olvasnom a leírást vagy hasonló rémségek.
https://github.com/openssl/openssl/blob/master/ssl/record/rec_layer_s3…
- NevemTeve blogja
- A hozzászóláshoz be kell jelentkezni
- 530 megtekintés
Hozzászólások
Ha emögött openssl s_client van, és nem használt -connect paramétert, akkor egyszerű a megoldás: add meg a --servername paramétert, hogy az SNI működésbe léphessen. Ezek a szerverek több site-ot is kiszolgálnak (hasonlóan a webszerverek virtuális hosztjaihoz, lásd Apache VirtualHost stb.), és a Server Name Identification dönti el, hogy melyik virtuális hoszthoz akarnak csatlakozni, és így tanúsítványt használják.
Az openssl dokumentáció tök jól leírja:
-servername name
Set the TLS SNI (Server Name Indication) extension in the ClientHello message to the given value. If -servername is not provided, the TLS SNI extension will be populated with the name given to -connect if it follows a DNS name format. If -connect is not provided either, the SNI is set to "localhost". This is the default since OpenSSL 1.1.1.
Even though SNI should normally be a DNS name and not an IP address, if -servername is provided then that name will be sent, regardless of whether it is a DNS name or not.
- A hozzászóláshoz be kell jelentkezni
Ez jogos, ha nem lenne SNI, az is egy jó ok lenne.
Járulékos információ: átmentem egy másik készülékre, ott sikeresen kapcsolódott:
SSL_CIPHER_description: TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD- A hozzászóláshoz be kell jelentkezni
Firefoxból most éppen megy valamennyire, aztán jön ez:
Hiba történt a következőhöz csatlakozáskor: release-assets.githubusercontent.com. Nem lehet biztonságosan kommunikálni a partnerrel: nincs közös titkosító algoritmus.
Hibakód: SSL_ERROR_NO_CYPHER_OVERLAP
Az egyik gyanúsított nyilván valamilyen céges lehallgatóprogram felügyelőprogram a gépemen.
- A hozzászóláshoz be kell jelentkezni
Van a gépeden / cégben SSL bontás? Sok disznóságot tud művelni.
- A hozzászóláshoz be kell jelentkezni
Asszem betudom valamilyen éberségi tűzfalazási megvigyázóprogramnak. Mondjuk van neki egy listája azokról az IP-címekről, amikhez nem akarja, hogy kapcsolódjak, és valamiért ezt úgy oldja meg, hogy szabotálja a TLS-kapcsolatfelépítést. Vagy valami.
- A hozzászóláshoz be kell jelentkezni
Az egyik gyanúsított nyilván valamilyen céges
lehallgatóprogramfelügyelőprogram a gépemen.
Ja, hogy valójában nem te kontrollálod a TLS kapcsolatot a két végpont között, hanem más terminálja. Akkor nem szabad semmin se meglepődni.
- A hozzászóláshoz be kell jelentkezni
Ha tls-bontás van, akkor a géped -- tls-bontás -- szerver között valahol nincs közös halmaza a támogatott titkosító algoritmusoknak. Nekem a géped és a tls-bontás közötti problémának tűnik - ahol gáz van, ott milyen algoritmusokat tud a kliens?
- A hozzászóláshoz be kell jelentkezni
Szerintem nincs ennyire kifinomulva, a védőprogram a beépül a TCP-kapcsolatba és ha nem rokonszenvezik a partnerrel [vö: blocklist] akkor a ServerHello-t saját hatáskörben küldi.
read from 0x7fffdbbd2dd0 [0x7fffdbbe6633] (5 bytes => 5 (0x5))
0000 - 15 03 03 00 02 .....
read from 0x7fffdbbd2dd0 [0x7fffdbbe6638] (2 bytes => 2 (0x2))
0000 - 02 28
Received TLS Record
Header:
Version = TLS 1.2 (0x303)
Content Type = Alert (21)
Length = 2
Level=fatal(2), description=handshake failure(40)
- A hozzászóláshoz be kell jelentkezni
Nálunk a kliensoldali ESET terminál minden HTTPS/SSL kapcsolatot, onnan tudod, hogy a partner tanusíványát nem a GlobeSSL hanem az ESET írta alá. Van is szívás ezzel rendesen, a megoldás mindig az, hogy ki kell lőni belőle azokat a kapcsolatokat, amikre nem akarod, hogy ráugorjon a MITM támadó modul.
- A hozzászóláshoz be kell jelentkezni