TLS 1.2 - Vaag probleem

[EricNL]

Mannen,

Geen idee waar ik om hulp kan vragen dus ik probeer het hier maar. Ik zal proberen het zo simpel mogelijk te omschrijven.



H1 & H2 zijn Windows Server 2008 hosts.
S1 & S2 zijn in dit geval de "SSL/TLS" servers (technisch XML gateways maar doet er eigenlijk niet toe).

H1 & H2 zitten in hetzelfde subnet (verschillen letterlijk 1 IP).

In bovenstaande tekening is al zichtbaar wat het probleem is. Beiden hosts zouden naar beiden servers een SSL (TLS1.2) verbinding op moeten kunnen zetten. H2 kan dit zonder probleem, echter kan H1 het maar naar 1 van de 2 servers.

Gateways van beiden Windows machines zijn gelijk, en met een tracert is ook zichtbaar dat beiden hosts naar beiden servers exact dezelfde routes afleggen.

Wat is dan het symptoom als H1 naar S1 probeert te connecten (getest d.m.v. OpenSSL + WireShark):
- Sessie van H1 naar S1 wordt geprobeerd op poort 443
- TCP Syn, Syn Ack en Ack worden netjes uitgewisselt tussen de 2 devices (routes zouden dus al zo goed als uitgesloten kunnen worden)
- Client Hello wordt verstuurd door H1
- ACK wordt verstuurd door S1
- Er komt geen Server Hello van S1 bij H1 binnen en sessie stopt daar.
- Een trace tegelijkertijd vanuit S1 toont wel aan dat er een Server Hello verstuurd wordt maar die komt om wat voor reden dan ook niet binnen bij H1.

Van H2 naar S1 werkt het wel en van H1 naar S2 dus ook. Het is alleen H1 naar S1.
Ik heb de NIC's van beiden Windows Servers naast elkaar gelegd en die zijn qua properties exact hetzelfde. Morgen wordt er nog getest wat er gebeurd als we het proces omdraaien (SSL sessie opzetten van S1 naar H1) maar als dat niks oplevert weet ik ook niet meer zo goed waar ik het in moet zoeken.

Beiden Windows Servers zijn VM's en mijn idee is dan ook om de werkende Windows machine (H2) te clonen en (desnoods tijdelijk) het IP te geven van H1, dan weten we eigenlijk zeker dat alle netwerkroutes etc. zijn uitgesloten maar we hebben te maken met een 3e partij en dan komt er gelijk een kostenplaatje bij kijken.

Wie of wie heeft de gouden tip?

[KillerAce_NL]

welk proces luistert er dan ? Misschien dat het daarin zit.
XML gateways ken ik maar van 2 vendors en dat zijn citrix en oracle.
Local firewall op s1 ?

[biomass]

Als het nog om 32-bits windows 2008 gaat, heb je deze al gelezen? https://blogs.microsoft.c...d-to-windows-server-2008/

Deze blog beschrijft wat je kunt tegen komen als je een .Net 4 applicatie op met TLS 1.2 wilt draaien...

https://www.codit.eu/blog...0-and-support-for-tls-12/

[EricNL]

biomass schreef op donderdag 24 augustus 2017 @ 17:39:
Als het nog om 32-bits windows 2008 gaat, heb je deze al gelezen? https://blogs.microsoft.c...d-to-windows-server-2008/

Deze blog beschrijft wat je kunt tegen komen als je een .Net 4 applicatie op met TLS 1.2 wilt draaien...

https://www.codit.eu/blog...0-and-support-for-tls-12/

Beiden zijn R2 servers (64-bit), beiden zelfde build (7601). Oftewel: servers zijn zo goed als identiek, en toch heeft 1 machine maar naar 1 server een probleem. Ik wil alles met plezier uitzoeken, maar ik weet gewoon niet meer goed waar te zoeken.

KillerAce_NL schreef op donderdag 24 augustus 2017 @ 17:38:
welk proces luistert er dan ? Misschien dat het daarin zit.
XML gateways ken ik maar van 2 vendors en dat zijn citrix en oracle.
Local firewall op s1 ?

Er komt letterlijk vanaf een [ACK] op de Client Hello vanaf de S1 naar de H1. Het enige wat ik weet is dat het een XML Gateway is die op Linux draait, maar Firewall zou al gechecked zijn en het dus ook niet (kunnen) zijn.

[ Voor 25% gewijzigd door EricNL op 24-08-2017 18:10 ]

[biomass]

Vergelijk in Wireshark de Client Hello en Server Hello pakketten tussen de machines. Misschien is volgorde van ondersteunde ciphers op niet overal gelijk, dan wordt de verbinding namelijk verbroken. Controleer ook of de TLS protocol versie in het Client Hello pakket echt 1.2 is.

"Check the SSL Cipher Suites and their order" in de blog. de plaatjes ontbreken daar (bij mij?) maar die zou je als eerste kunnen vergelijken.

[EricNL]

biomass schreef op donderdag 24 augustus 2017 @ 18:28:
Vergelijk in Wireshark de Client Hello en Server Hello pakketten tussen de machines. Misschien is volgorde van ondersteunde ciphers op niet overal gelijk, dan wordt de verbinding namelijk verbroken. Controleer ook of de TLS protocol versie in het Client Hello pakket echt 1.2 is.

"Check the SSL Cipher Suites and their order" in de blog. de plaatjes ontbreken daar (bij mij?) maar die zou je als eerste kunnen vergelijken.

Ik zie wel iets vreemds. Het verkeer moet gewoon TLS 1.2 zijn. Dit is het gene wat ik zie als ik bij beiden Windows hosts connect met "openssl s_client -connect IP:443 -tls1_2:

Werkende machine:



Niet Werkende machine


En ondanks in de packets wel degelijk Type: TLS1.2 staat is dit het enige wat ik afwijkend vind. En ja, het zijn interne adressen maar vanwege gevoeligheid toch even geblurred.

[biomass]

De Client Hello pakketten kun je inspecteren, wat is de inhoud? (dubbelklik geloof ik). Als de Client Hello's hetzelfde zijn, is er een verschil (in (volgorde van) ondersteunde ciphers) tussen de servers.

Oh wacht, je niet werkende machine reageert als SSL. Dat betekent dat de SChannel config in het registry nog geen TLS ondersteuning heeft (staat ook in de blog). Die kun je toevoegen, na een reboot zou de Client request wel TLS 1.2 moeten zijn. Makkelijkste check, vergelijk eerst het registry van je twee clients

[ Voor 43% gewijzigd door biomass op 24-08-2017 18:57 ]

[EricNL]

biomass schreef op donderdag 24 augustus 2017 @ 18:54:
De Client Hello pakketten kun je inspecteren, wat is de inhoud? (dubbelklik geloof ik). Als de Client Hello's hetzelfde zijn, is er een verschil (in (volgorde van) ondersteunde ciphers) tussen de servers.

Oh wacht, je niet werkende machine reageert als SSL. Dat betekent dat de SChannel config in het registry nog geen TLS ondersteuning heeft (staat ook in de blog). Die kun je toevoegen, na een reboot zou de Client request wel TLS 1.2 moeten zijn. Makkelijkste check, vergelijk eerst het registry van je twee clients

Cipher Suites zijn er exact evenveel. Of ze allemaal ook op exact dezelfde volgorde staan weet ik niet 100% zeker maar het lijkt er wel sterk op (het waren er namelijk 82). Ik heb nu via OpenSSL de "ECDHE-RSA-AES256-SHA384" suite geforceerd omdat dit het gene was wat in de werkende connectie er door kwam maar ook dan hetzelfde resultaat: na de Client Hello stopt het...

[biomass]

Zie je verschillen in het registry op je clients H1 & H2 onder[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
?

[Vorkie]

Zijn de certificaten van de servers volledig ingeladen / correct?

[EricNL]

Vorkie schreef op donderdag 24 augustus 2017 @ 19:10:
Zijn de certificaten van de servers volledig ingeladen / correct?

Hier komen we bij mij een beetje op een grijs gebied. Ik zie wel degelijk wat Certificaten + sleuteltje staan in de mmc, maar waar moet ik naar kijken? Als ik via OpenSSL s_client een -connect doe, welk certificaat zou er dan gebruikt "moeten" worden. Anders gezegd, wat kan/moet ik precies controleren?

[Vorkie]

EricNL schreef op donderdag 24 augustus 2017 @ 19:13:
[...]


Hier komen we bij mij een beetje op een grijs gebied. Ik zie wel degelijk wat Certificaten + sleuteltje staan in de mmc, maar waar moet ik naar kijken? Als ik via OpenSSL s_client een -connect doe, welk certificaat zou er dan gebruikt "moeten" worden. Anders gezegd, wat kan/moet ik precies controleren?

De eigenschappen, ze zouden gelijk moeten zijn, anders dan de DNS naam / SAN naam natuurlijk

Weet niet zeker, maar zijn de ook de private keys aanwezig?

[EricNL]

Vorkie schreef op donderdag 24 augustus 2017 @ 19:16:
[...]

De eigenschappen, ze zouden gelijk moeten zijn, anders dan de DNS naam / SAN naam natuurlijk

Weet niet zeker, maar zijn de ook de private keys aanwezig?

Hier zal ik iets meer hulp bij nodig moeten hebben. Er staan meerdere Certificaten in de store. Hoe weet ik naar welk certificaat ik moet kijken?

biomass schreef op donderdag 24 augustus 2017 @ 19:09:
Zie je verschillen in het registry op je clients H1 & H2 onder[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
?

Zojuist de gehele SCHANNEL tree van beiden machines vergeleken maar enige wat afwijkt is:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]
"EventLogging"=dword:00000001

Op de niet werkende machine staat deze op 00000003 maar kan me niet voorstellen dat dit een probleem is.

[ Voor 39% gewijzigd door EricNL op 24-08-2017 19:18 ]

[biomass]

Heb je op beide machines ook deze instellingen?
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
   "SchUseStrongCrypto"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]
   "SchUseStrongCrypto"=dword:00000001

Aangezien je niet werkende verbinding wordt geinitieerd als SSL moet het een client issue zijn. Dus die eventlogging op dword:00000003 kan een probleem zijn.

Is het mogelijk dat de niet werkende machine wel alle instellingen heeft gekregen, maar daarna nooit is herstart?

[EricNL]

biomass schreef op donderdag 24 augustus 2017 @ 19:27:
Heb je op beide machines ook deze instellingen?
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
   "SchUseStrongCrypto"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]
   "SchUseStrongCrypto"=dword:00000001

Aangezien je niet werkende verbinding wordt geinitieerd als SSL moet het een client issue zijn. Dus die eventlogging op dword:00000003 kan een probleem zijn.

Is het mogelijk dat de niet werkende machine wel alle instellingen heeft gekregen, maar daarna nooit is herstart?

Beiden machines hebben deze keys niet. Het probleem speelt ook al een tijd, en de niet-werkende machine is onlangs nog herstart.

Misschien kan ik het verschil in Wireshark output verklaren. De ene machine heeft nog Wireshark v1.10.10 en de andere heeft Wireshark 2.2.6. Zoals ik al zei staat in de daadwerkelijke SSL/TLS packet heel duidelijk: Type: TLSv1.2

[PerfectPC]

Vergeet certificaten voorlopig even, die zijn nog niet aan de orde als het al misloopt net na de client hello.
In je eerste post zeg je dat de server hello wel vertrekt, maar niet aankomt. Kan je dat staven met wireshark captures? zoja verdenk ik ergens een mtu setting die scheef staat... (server hello is het eerste grote packet) dit kan je eventueel even testen met een ping -l

[ Voor 6% gewijzigd door PerfectPC op 24-08-2017 19:50 ]

[EricNL]

PerfectPC schreef op donderdag 24 augustus 2017 @ 19:47:
Vergeet certificaten voorlopig even, die zijn nog niet aan de orde als het al misloopt net na de client hello.
In je eerste post zeg je dat de server hello wel vertrekt, maar niet aankomt. Kan je dat staven met wireshark captures? zoja verdenk ik ergens een mtu setting die scheef staat... (server hello is het eerste grote packet) dit kan je eventueel even testen met een ping -l

Ik kan wel e.e.a. checken. Morgen willen we ook nog een testje doen om het even om te draaien. Oftewel: een SSL connectie opzetten van S1 naar H1.

Het vreemde is: ik heb van mijn collega een trace gekregen van 2 maanden geleden waarin WEL een Server Hello te zien is naar de H1.

[Kabouterplop01]

Werkt de verbinding/applicatie wel op http?

[EricNL]

Weer een update. Ik heb nu tegelijkertijd een trace uit kunnen voeren op alle relevantie system. Wat vooral opvalt is dat de Server Hello naar de niet werkende machine (H1) pas 60 seconden na het ontvangen van de Client Hello verstuurd wordt.

H1 naar S1:


S1 naar H1:


H2 naar S1:


S1 naar H2:

[Vorkie]

Tussen S1 en H2 gaat het fout met het certificaat zo te zien. Kan S1 toevallig de complete certificate chain niet ophalen? Dan meen ik mij te herinneren dat ie "online" probeert op te halen, maar als die dan geen internet heeft, dit fout gaat.

[EricNL]

Vorkie schreef op vrijdag 25 augustus 2017 @ 10:51:
Tussen S1 en H2 gaat het fout met het certificaat zo te zien. Kan S1 toevallig de complete certificate chain niet ophalen? Dan meen ik mij te herinneren dat ie "online" probeert op te halen, maar als die dan geen internet heeft, dit fout gaat.

Hij geeft uiteindelijk een warning vanwege z'n certificaat maar dat is in dit geval de bedoeling. Die SSL handshake is wel verder wel degelijk in orde. Het probleem is dus echt H1 naar S1 en dat het gewoon stopt na de Client Hello afkomstig van de H1. De S1 reageert wel met een Server Hello maar pas heel laat, en die bereikt H1 ook niet...

[Vorkie]

EricNL schreef op vrijdag 25 augustus 2017 @ 10:57:
[...]


Hij geeft uiteindelijk een warning vanwege z'n certificaat maar dat is in dit geval de bedoeling. Die SSL handshake is wel verder wel degelijk in orde. Het probleem is dus echt H1 naar S1 en dat het gewoon stopt na de Client Hello afkomstig van de H1. De S1 reageert wel met een Server Hello maar pas heel laat, en die bereikt H1 ook niet...

Ja inderdaad, ik zat verkeerd te kijken.

Staat beide servers op dezelfde virtuele host? (een traceroute zegt niet zo heel veel, er kunnen best transparante devices tussen zitten)

[EricNL]

Vorkie schreef op vrijdag 25 augustus 2017 @ 11:01:
[...]

Ja inderdaad, ik zat verkeerd te kijken.

Staat beide servers op dezelfde virtuele host? (een traceroute zegt niet zo heel veel, er kunnen best transparante devices tussen zitten)

Yes, beiden op dezelfde host. Misschien zit/zat PerfectPC wel op een goed spoor: het moment dat het fout lijkt te gaan is na de 1e ACK na de Client Hello vanaf S1 naar H1. Daarna zie je retransmits komen. Dat verklaart vrij simpel waarom hij de Server hello pas na ongeveer 1 minuut stuurt. Het zou zeker een MTU probleem kunnen zijn, maar waar begin je mee. De tussenliggende infra kan het eigenlijk niet zijn, anders zou H2 het probleem ook moeten hebben, en op de Windows machines zelf zie ik geen verschil in MTU settings.

[Vorkie]

EricNL schreef op vrijdag 25 augustus 2017 @ 11:05:
[...]


Yes, beiden op dezelfde host. Misschien zit/zat PerfectPC wel op een goed spoor: het moment dat het fout lijkt te gaan is na de 1e ACK na de Client Hello vanaf S1 naar H1. Daarna zie je retransmits komen. Dat verklaart vrij simpel waarom hij de Server hello pas na ongeveer 1 minuut stuurt. Het zou zeker een MTU probleem kunnen zijn, maar waar begin je mee. De tussenliggende infra kan het eigenlijk niet zijn, anders zou H2 het probleem ook moeten hebben, en op de Windows machines zelf zie ik geen verschil in MTU settings.

En beide dezelfde netwerkkaart? e1000 of vmxnet3?Bij VMware dan

[EricNL]

Vorkie schreef op vrijdag 25 augustus 2017 @ 11:06:
[...]

En beide dezelfde netwerkkaart? e1000 of vmxnet3?Bij VMware dan

Beiden vmxnet3. Settings op de adapter ook exact hetzelfde.

[Vorkie]

EricNL schreef op vrijdag 25 augustus 2017 @ 11:07:
[...]


Beiden vmxnet3. Settings op de adapter ook exact hetzelfde.

Heeft het een reden dat de ene server al bij LAN Connection 5 is en de niet werkende pas bij LAN connection 3?

EricNL schreef op vrijdag 25 augustus 2017 @ 11:09:
[...]


Nee voor zo ver ik weet niet. Zojuist voor de zekerheid op beiden machines MTU gechecked en allen op 1500.

Wordt er NSX gebruikt? Staan beide firewalls uit / private / domain mode? Zijn er meerdere connected LAN netwerken? Kunnen ze beide internet op / of juist niet? Of eentje wel en de andere niet.

[ Voor 42% gewijzigd door Vorkie op 25-08-2017 11:11 ]

[EricNL]

Vorkie schreef op vrijdag 25 augustus 2017 @ 11:08:
[...]

Heeft het een reden dat de ene server al bij LAN Connection 5 is en de niet werkende pas bij LAN connection 3?

Nee voor zo ver ik weet niet. Zojuist voor de zekerheid op beiden machines MTU gechecked en allen op 1500.

Vorkie schreef op vrijdag 25 augustus 2017 @ 11:08:
[...]
Wordt er NSX gebruikt? Staan beide firewalls uit / private / domain mode? Zijn er meerdere connected LAN netwerken? Kunnen ze beide internet op / of juist niet? Of eentje wel en de andere niet.

- NSX zegt mij niets
- Op beiden staan Firewall volledig uit
- Geen virusscanners etc.
- Beiden hebben 3 LAN verbindingen.
- Internet werkt op beiden.

[ Voor 40% gewijzigd door EricNL op 25-08-2017 11:14 ]

[Vorkie]

EricNL schreef op vrijdag 25 augustus 2017 @ 11:09:
[...]


Nee voor zo ver ik weet niet. Zojuist voor de zekerheid op beiden machines MTU gechecked en allen op 1500.


[...]

- NSX zegt mij niets
- Op beiden staan Firewall volledig uit
- Geen virusscanners etc.
- Beiden hebben 3 LAN verbindingen.
- Internet werkt op beiden.

En wat is de volgorde van de netwerk kaarten?

https://social.technet.mi...owsserver2008r2networking

[EricNL]

Vorkie schreef op vrijdag 25 augustus 2017 @ 11:18:
[...]

En wat is de volgorde van de netwerk kaarten?

https://social.technet.mi...owsserver2008r2networking

Ook al gechecked inderdaad: op beiden staan de LAN adapters in exact dezelfde volgorde (ondanks dat de ene adapter op de ene machine nummer 6 is en op de andere nummer 4).

[Thralas]

EricNL schreef op vrijdag 25 augustus 2017 @ 11:05:
Het zou zeker een MTU probleem kunnen zijn, maar waar begin je mee.

Je probleem proberen te minimaliseren door bv. ping met oplopende payload length.

[EricNL]

Thralas schreef op vrijdag 25 augustus 2017 @ 12:39:
[...]


Je probleem proberen te minimaliseren door bv. ping met oplopende payload length.

Dat heb ik vanaf beiden Windows hosts naar de SSL server (S1) gedaan en komen beiden op hetzelfde uit... Ik begon daarom ook steeds meer een vermoeden te krijgen dat het probleem onstaat op de S1. Helaas (voor mijn kennis) is dat een Linux bak, dus dan kom ik op heel ander terrein

[PerfectPC]

heb je een oplossing gevonden?