none
c# - Brainpool-Unterstützung ab .NET 4.7 RRS feed

  • Frage

  • Hallo,

    ich versuche gerade einen TCP-Server zu entwickeln, der sich mittels ECC-Zertifikat ausweist. Die zugrunde liegende Kurve ist brainpoolP384r1. Für die Verbindung nutze ich die Klasse System.Net.Security.SslStream.

    Angeblich soll das mit Version 4.7 des .NET Frameworks funktionieren. In Realität sieht das aber leider so aus, dass der SSL-Handshake nach dem "Client Hello" mit [FIN,ACK] beendet wird, also fehlschlägt. Wenn ich jetzt ein Zertifikat nutze, dass exakt gleich aussieht, aber als Kurve secp384r1 verwendet, klappt der Handshake. Die Methode SslStream.BeginAuthenticateAsServer wird in beiden Fällen fehlerfrei durchlaufen.

    Weitere Forschung hat ergeben, dass Brainpool anscheinend seitens SCHANNEL nicht unterstützt wird. Heißt das, dass die Unterstützung durch das .NET Framework in diesem Fall leider sinnlos ist?

    Oder gibt es eine Möglichkeit, das zu ändern (irgendwelche "Registry-Magic")? 

    Viele Grüße,

    Frank

    Mittwoch, 21. Februar 2018 06:37

Alle Antworten

  • Möglicherweise ist es eine Frage der Version:

    Unter TLS (Schannel SSP) changes in Windows 10 and Windows Server 2016 steht

    Added support for the following elliptical curves:

    BrainpoolP256r1 (RFC 7027) in Windows 10, version 1507 and Windows Server 2016
    BrainpoolP384r1 (RFC 7027) in Windows 10, version 1507 and Windows Server 2016
    BrainpoolP512r1 (RFC 7027) in Windows 10, version 1507 and Windows Server 2016
    Curve25519 (RFC draft-ietf-tls-curve25519) in Windows 10, version 1607 and Windows Server 2016

    Wird also noch nicht so lange unterstützt.


    - Gruß Florian

    Donnerstag, 22. Februar 2018 09:40
  • Vielen Dank, die Seite hatte ich nicht gefunden. Eigentlich sollte das auf meinem Rechner unterstützt werden, ich habe Windows 10, Version 1709 installiert und

    certutil -DisplayEccCurve 

    gibt mit ebenfalls aus, dass die Brainpoolkurven unterstützt werden.

    Damit kann ich SCHANNEL also eigentlich als Schuldigen ausschließen. Stellt sich nur die Frage, warum geht es trotzdem nicht? Ich finde keinen Ansatzpunkt, an dem ich herausfinde, warum der Handshake fehlschlägt, bzw. beim Aufruf mittels

     openssl s_client -connect myserver:9999

    kein Zertifikat zurückkommt:

    CONNECTED(0000020C)
    ---
    no peer certificate available
    ---
    No client certificate CA names sent
    ---
    SSL handshake has read 0 bytes and written 308 bytes
    ---
    New, (NONE), Cipher is (NONE)
    Secure Renegotiation IS NOT supported
    Compression: NONE
    Expansion: NONE
    No ALPN negotiated
    SSL-Session:
        Protocol  : TLSv1.2
        Cipher    : 0000
        Session-ID:
        Session-ID-ctx:
        Master-Key:
        Key-Arg   : None
        PSK identity: None
        PSK identity hint: None
        SRP username: None
        Start Time: 1519294294
        Timeout   : 300 (sec)
        Verify return code: 0 (ok)
    ---
    

    Mit der secP384r1-Kurve kommt das Zertifikat zurück und der Handshake funktioniert.

    Gibt es eine spezielle Stelle im SslStream, an der man sich per Debugger einklinken kann, um herauszufinden was genau schiefläuft?

    Gruß,

    Frank

    Donnerstag, 22. Februar 2018 10:13