2016-10-24 3 views
17

Ich versuche, ein Gerät mit einem .Net (4.5.2) -Server zu verbinden. Es ist eine TCP-Verbindung, die von dem Gerät geöffnet wird, das TLS 1.2 verwendet.Verbinden eines Clients mit einem TCP-Server mit TLS 1.2

  • Auf der Serverseite habe ich eine Standard-.NET-Implementierung eines TCP-Server: SslStream durch eingewickelt DotNetty
  • I
  • auf dem Gerät nichts ändern können

Jeder Client .Net erfolgreich verbinden zu meinem Server mit einer gesicherten TLS-Verbindung. Es funktioniert auch beim Versuch mit CURL, also habe ich festgestellt, dass mein TCP-Server funktioniert.

Also ich habe verglichen (mit Wireshark), was von einem funktionierenden Client gesendet wurde, von dem, was von dem Gerät gesendet wurde, das nicht verbinden kann. Der signifikante Unterschied, den ich gefunden habe, ist die Abwesenheit (für das Gerät) der Server Name Extension (SNI) innerhalb der Client Hello TLS Nachricht.

Als nächstes habe ich versucht, Daten manuell an meinen Server mit Pcap.Net zu senden, dh TCP SYN/TCP ACK/Client Hallo Nachrichten mit rohen Byte-Arrays manuell zu senden (Rohdaten habe ich (dank Wireshark) vom Gerät versucht um sich mit meinem Server zu verbinden). Ich habe bestätigt, dass die Optimierung des nicht funktionierenden Client-Hello-Rohbytearrays durch Hinzufügen der Servernamenerweiterung dazu führt, dass mein TLS-Handshake funktioniert.

Also offensichtlich habe ich ein Problem mit Clients, die nicht die SNI-Erweiterung und einen Server, der den Handshake verweigert, wenn diese Informationen nicht vorhanden ist.

Wie kann ich die Art und Weise ändern, wie sich mein TCP-Server verhält, um Clients zu akzeptieren, die nicht die Erweiterung des Server-Namens enthalten? Ist es in erster Linie möglich, die Standardklasse .Net SslStream zu verwenden?

AFAIK, die SNI-Erweiterung ist nicht obligatorisch, und es liegt an dem Client zu entscheiden, ob oder nicht zu verwenden, so sollte der Server theoretisch eine Client-Hallo-Nachricht ohne es akzeptieren.

Jeder Zeiger würde sehr geschätzt werden.

+0

Ich habe Angst .NET keine Kontrolle über diese hat - 'SslStream' ist nur ein verwaltetes Wrapper für SChannel und ist nicht immer miteinander ausgehen. Haben Sie versucht, den Callback für die Zertifikatsvalidierung zu stören? Ist der Client Hello gut für Sie? Kannst du es weiter reduzieren, damit es funktioniert? – Luaan

+0

als Nebenprodukt kann Ihr Client-Gerät * alle * TLS1.2-Verbindungen herstellen? z.B. über einen Browser auf eine bestimmte https-Website? – wal

+0

Wenn Sie unbedingt arbeiten müssen, könnten Sie eine andere Implementierung von SSLStream in Erwägung ziehen, zB ein Produkt wie dieses https://www.eldos.com/sbb/descs-ssl-spec.php (ich befürworte nicht nur die erste Alternative i gefunden) – wal

Antwort

1

.Net 4.5.2 unterstützt TLS1.2, ist jedoch standardmäßig deaktiviert.

Zur Aktivierung müssen Sie das Sicherheitsprotokollset explizit definieren.

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls; 

weitere Informationen finden Sie den folgenden Link https://msdn.microsoft.com/en-us/library/system.net.servicepointmanager.securityprotocol%28v=vs.110%29.aspx

+0

Neugierig, wenn dies innerhalb von API-Calls möglich ist. – brendo234

+0

@ brendo234 Ich bin mir nicht sicher zu verstehen, was du meinst. System.Net.ServicePointManager.SecurityProtocol ist ein API-Aufruf. – cristallo