none
SECURITY-CONCERN - Missing documentation on how clients CAN/SHOULD get SSL Certificates from C#/TcpListener based applications. RRS feed

  • Question

  • Please help,

    I have a security concern about lack-of/missing documentation on how client CAN/SHOULD get SSL Certificates from C#/TcpListener based applications. I am especially concerned as with any C#/TcpListener based application, there is the fact that on the first client-to-server request (https), the client will never have any required SSL Certificate unless it is put there somehow, someway, and all the documentation I've seen in MSDN, totally does not even slightly acknowledge that this happens, in my opinion.

    In building a C#/TcpListener based server, of which MSDN has lots of docuemntationon, too include running TcpListener.AcceptTcpClient to SslStream.AuthenticateAsServer, there is nothing on how clients CAN/SHOULD get SSL Certificates in the first place, from the same TcpListener based server. In fact, no documentation seems to exist on how clients should get them automatically, from a C#/TcpListener based server in an automated fashion at all.

    In all documentation I've found from web searches, they all start that somehow the client just has the SSL Certificate, and then it uses https communication to the Server, where say a C# based TcpListener, would use SslStream.AuthenticateAsServer to then know if a clients request is secure or not.

    As an example, take these MSDN links on: TcpListener.AcceptTcpClient, SslStream.AuthenticateAsServer and the X509Certificate Class.

     - https://msdn.microsoft.com/en-us/library/system.net.sockets.tcplistener.accepttcpclient(v=vs.110).aspx
     - https://msdn.microsoft.com/en-us/library/system.net.security.sslstream.authenticateasserver(v=vs.110).aspx
     - https://msdn.microsoft.com/en-us/library/system.security.cryptography.x509certificates.x509certificate(v=vs.110).aspx

    In those links, and further links from them, they do not document how a client CAN/SHOULD get SSL Certificates from the same application about to run SslStream.AuthenticateAsServer for a X509Certificate.

    So, with no documentation/guidelines, one is left to figure this out on their own, which will surely lead to security issues.

    To clarify, IIS is NOT part of this solution. This is a pure C#/TcpListener based application.

    Wednesday, October 18, 2017 7:56 PM

All replies

  • Please help,

    I'm trying to make a C# Web Server, that provides HTTP/SSL. Making a HTTP Web Server with C#, is pretty easy, for which I'm providing code below that I want to do something with, to then complete it having full HTTPS/SSL.

    For ease of reading, I will STRESS "HTTPS" instead of saying SSL, or even mention TLS. I am aware of TLS, and the concept of SSL/TLS handshake, with many references, but I've found by even slightly mentiong TLS, or NOT including HTTPS before SSL, that the discussion from others jumps to the client already knows it has to go https, and it somehow already has the certificate.

    The above said, the trick I need done would follow in the steps for the FULL handshake from client to server from rock-bottom scratch, where the client has never before called to the server as such:

    1) Client is a standard HTML5 compliant browser like Edge/Chrome, and it has HTTP (not-secure) url to my C# server, like http://MyServer/~~~. Note, "http" - NO "S", NOT Secure.

    2) Server, after getting past Listener.AcceptTcpClient(), KNOWS that the clients request does NOT have any HTTPS to it.

    3) Server then does something, to tell client, here is the HTTPS url you should use, and here is a HTTPS/SSL Certificate to this url that you should use. A possible 303/Redirect with the correct url having https (secure with "S"), gets returned.
     - - Almost assuredly, the server would need to have a second TCP listener, that monitors the HTTPS/SSL, and that is OK.

    4) Client gets the correct URL, maybe some other step occurs, but it knows to use https. BUT, it does not have the certificate.

    5) Maybe at the same time, as Step (4), the client, gets the HTTPS/SSL Certificate.

    6) Client then uses the correct URL (with https with "S"), and the certificate.

    7) Server in likely a second TCP listener, gets past its Listener.AcceptTcpClient() for the https url and runs some SslStream.AuthenticateAsServer and finally knows the client is good to go.

    Wednesday, October 18, 2017 6:28 PM
  • Hi JSB,

    >>how client CAN/SHOULD get SSL Certificates from C#/TcpListener based applications.

    Do you want to know how Client validate Server certificate or Server validate Client certificate?

    For client side, it validates server’s certificate by specifying a RemoteCertificateValidationCallback delegate when creating an SslStream.

    For server side, also control validation by supplying a RemoteCertificateValidationCallback delegate.

    You could refer SslStream which provides a stream used for client-server communication that uses the Secure Socket Layer (SSL) security protocol to authenticate the server and optionally the client for more information.

    https://msdn.microsoft.com/en-us/library/system.net.security.sslstream.aspx#Anchor_5

    Authentication process, also known as the SSL handshake.

    #Description of the Secure Sockets Layer (SSL) Handshake

    https://support.microsoft.com/en-in/help/257591/description-of-the-secure-sockets-layer-ssl-handshake

    Best Regards,

    Edward


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Thursday, October 19, 2017 2:43 AM
    Moderator
  • Hi JSB,

    >> Client gets the correct URL, maybe some other step occurs, but it knows to use https. BUT, it does not have the certificate

    It depends on whether the server requires client certificate for validation. If not, the client will use the public key from server side to encrypt the information.

    Best Regards,

    Edward


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Thursday, October 19, 2017 2:53 AM
    Moderator
  • Thank you for the reply Edward. Sorry for any misconception. This issue has nothing to do with validation.

    It is about how the client CAN/SHOULD get the certificate from a TcpListener application.

    When a client, browses for the 1st time to web site, that is a C# TcpListener based app, using a https baed url, the client on that 1st time, does not have any SSL certificate on the site it is going to.

    Somehow, the TcpListener app, gives the client a SSL Certificate to use, and from there, the client gets the SSL Certificate, and then tries to use it.

    The documentation on TcpListener is mum on how the client CAN/SHOULD gets the certificate from the TcpListener server. This is a big security hole to me, as it leaves developers to have to guess what to do.

    In real life, if one's client browses to any https based url, for the first time, a handshake process occurs, that causes the server to send down to the client a SSL Certificate to use. I've personally seen this with various site, using Fiddler to trace, but I do not know how to do this handshake with C#/TcpListener based applications, as there is no documentation on how the client CAN/SHOULD get the SSL Certificate at all, even manually, albeit, I'm looking for the proper automatic way that professional web sites (https://www.micorsoft.com, https://www.yahoo.com, etc) work. And again, IIS, is NOT part of this issue.

    Thursday, October 19, 2017 1:45 PM
  • Thanks for the reply.

    After more research, I've decided to redo the steps as shown below, where the client just knows to use https up front, for the first time, and otherwise does not need to do a http-to-server-then-redirect.

    But, the issue is not hinged on "validation". It is hinged on how the server gives the client a SSL Certificate. At any rate, here are the revised steps:

    1) Client browses to an HTTPS url for the first time, where it has never been to before. The client has not a single SSL Certificate for anything, let alone to the url it tries to go to.

    2) Somehow, between a handshaking process between the client to server, the client gets at least 1 SSL Certificate, that it then uses to continue making HTTP requests to the server.

    3) After the client gets at least 1 SSL Certificate and sends a HTTP request (like a GET or POST), the Server's TCP listening, gets past its Listener.AcceptTcpClient() and runs some SslStream.AuthenticateAsServer and finally knows the client is good to go, and then returns data to the client. It does not matter if the client requires "mutual" ssl validation in the SslStream.AuthenticateAsServer .

    Well, I hope I've better stated this. The Step (2) is the mystery, and it has nothing to do with validation, but I sense there is no technical phrase to describe this, as I've done hours of research, and I've not found anything to focus on the "get the SSL Certificate" to the client.

    Thursday, October 19, 2017 2:32 PM
  • Hi JSB,

    It seems you want to know the depth implementation of how client and server process SSL Handshake, I am afraid there is no such documentation.

    From Reference Source, I fail to find anything about this process.

    Best Regards,

    Edward


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Friday, October 20, 2017 2:37 AM
    Moderator
  • Thanks for the reply Edward.

    I'm not looking for the handshake, that does not explain CAN/SHOULD of how a SSL Cert gets to the client in the 1st place.

    I'm going to rack this up as I do not know how to ask the question correctly, and barring that, let's consider this thread resolved. But thanks so much for the replies still.

    Monday, October 23, 2017 5:22 PM
  • Hi JSB,

    In general, we mark the helpful reply as answer to close the thread here.

    But, it seems there is no solution for your issue in this thread. You may consider marking last as answer to indicate this thread is closed.

    Regards,

    Tony


    Help each other

    Tuesday, October 24, 2017 2:44 AM
  • As per the SSL TCP Server / Client socket example provided here

    https://docs.microsoft.com/en-us/dotnet/api/system.net.security.sslstream?redirectedfrom=MSDN&view=netframework-4.7.2#Anchor_5

    There is method call sslStream.AuthenticateAsServer(serverCertificate,..)

    This method internally does the heavy-loading work of passing certificate to client, client validating it and returning client feedback.

    After this method call, a new stream is created which has to used for reading and writing and the original socket.GetStream is closed.

    Just fyi, the example also shows option to authenticate client, forcing client to return the client certificate and validating that also.. by implementing ValidateClientCertificate callback method.. similar to  ValidateServerCertificate callback method in the Server implementation part.

    Friday, September 28, 2018 7:16 AM