I am trying to send information (in the form of an mime file) to a third party host server that uses two way authentication. After much coaxing I got enough information from their non technical help desk staff to figure out that it is most likely a type of TLS/SSL communication. They use client and server handshakes. I found the following example:
sslstream example. But am having problems using it (TcpClient refuses to see the host adddress).
Before I get too far I was hoping some one could point me in the direction of some good examples or more information on this process. I'm feeling pretty lost.
By two way authentication, probably they mean that they require a client certificate. This means that during the handshake, the client side has to present a certificate to the server as well. The most common SSL behavior is that only the server part presents a certificate, such as when you go to a normal site that is using HTTPS.
As for SslStream, it is quite straightforward to use. To be able to present a client certificate, you need to have a certificate in the certificate store or a pfx file that you can load into memory during runtime.
I found this sample which seems good enough. Here is another one. The second one doesn't use client certs, but you can add them as a parameter to the the AuthenticateAsClient call.
If the TcpClient is refusing to see the host address, then this is most likely some kind of connectivity issue and not related to the actual SSL implementation.
Related
I am trying o figure out how CoAP server handles authentication. DTLS seems to be the only option. However I could not find any clear example of it for .NET. I have also seen a mention about cookie on server side but that is all, no more information.
https://github.com/chkr1011/CoAPnet seems to be a good library. They also have a client example but I sould not find server example of it. Projest seems to have CoAP server as well, however I could not find it in source code.
Can any client send requests to the server if url is known? Is DTLS the way to go? Is there any server/client example of DTLS in C#?
If a java server will also help, have a look at eclipse/californium. We run a sondbox at "californium.eclipse.org" and if you want to "connect" a client, you may just use the "openssl" PSK demo credentials "Client_identity" and "secretPSK".
Can any client send requests to the server if url is known?
That depends on the protocol variant. Without encryption (plain coap), yes. Some projects then use a "token" in the request, to authenticate the request (see ThingsBoard). With encryption (DTLS, coaps), you need valid credentials, e.g. PSK (as above), a x.509 certificate or a Raw Public Key certificate. There are also setups, where only the server authenticates itself using x.509, and the client then uses the already encrpyted communication to authenticate with an other mechanism (e.g. username/password, so very similar to the model, mostly used with https).
The most pain is usually to find implementations, which could be used in the intended/wanted way. Maybe some projects helps you, to adapt the implementation.
Is DTLS the way to go?
In my opinion, yes. The alternative with OSCORE (payload encryption) are currently in development, we will see, if that changes the game.
Is there any server/client example of DTLS in C#?
I don't know that. Maybe you ask that the project you already found. Or ask here CoAP-CSharp
I am using WebClient to implement a secure account check before a customer can use my application. but what I am worrying about is "does connecting to a website that uses SSL Certificate using HTTPS protocol prevent MATM attack and makes the whole communication encrypted ?".
In another words: will some programs like Wireshark be able to get the requests and responses in plain text as with using normal HTTP requests ? and is there an ability to alter the sent and received packets ? in order to change my application behavior or something.
[NOTE] I am not talking about getting my application pirated as I know that there is no way to get away from that fate.
HTTPS does prevent Man in the middle attack, as long as both sides are implementing the protocol properly and I assume that WebClient is implemented properly.
That means that even wireshark that is installed on your local box won't be able to decrypt the traffic
If someone in the middle would alter packets on their way, the other side won't be able to read them and the communication would break.
Some clarification given our discussion in your comments:
The above holds if your client is not compromised (HTTPS does work), since you are assuming that your clients will compromise themselves and use tools that will cheat your application by adding fake trusted certificates (which requires admin rights), I can suggest you to use two way ssl.
The tools that I know like Fiddler won't be able to decrypt this just by adding their trusted certificates, thus making it more difficult for your clients to attack your application this way, and bring them to use a debugger or patch it, because it is easier than implementing a two way ssl proxy.
You can also do what's described in this post to override the framework's certificate verification with code that expects one specific certificate and ignores the system's trusted certificates, which is compromised by tools like Fiddler (this implements What Mark suggested).
HTTPS encrypts the transmitted data and prevents man in the middle attacks by authenticating the HOST you are connecting to. However, in regards to a desktop application and also a web application, the user can use wireshark or an http proxy to view the contents of the https transmissions on the local host.
A way to mitigate this problem is to hard code the thumb print of your server cert so that you r application can encure that the server it's connecting to is presenting a specific certificate.
An example, would be if you were to install Fiddler on your local box and install the fiddler root certificate. Your application would think it's securely connecting to the server, but fiddler would be in the middle decrypting traffic. If your application code looks for a specific certificate thumbprint, you can throw an exception when a certificate other than the certificate you expect is used to connect, thus preventing the transmission of any data when a local proxy is in use.
Wireshark will always be able to see the packets being transmitted over the network but you won't necessarily be able to see the contents of the transmission unencrypted. However I'm not an expert in using Wireshark, so maybe someone else here can expound on that.
UPDATE
Ok to clarify more.... this question is discussing the encryption of contents being sent from a desktop application to a server.
Let's layout some assumptions:
The user of the desktop application, controls their desktop.
The application installed on the desktop is using a public key to encrypt.
Anyone with the corresponding private key can decrypt.
Since the user controls their desktop they can also run an http proxy on their desktop.
Now the way SSL(HTTPS) works is that your browser starts a secure handshake, at which point the server will return the public certificate, and your browser will attempt to authenticate that certificate with the authority you puchased the certificate from like (godaddy, geotrust, or versign, etc)
Assuming the user installed fiddler and it's root certificate, your desktop application would connect to fiddler, and be served fiddlers public root certificate, which it would validate against the locally certificate store and deem it trusted. Fiddler would then contact the server, which would send it the real public certificate.
Subsequently your http request from the browser is encrypted by the browser using the fiddler root public key, fiddler then decrypts the contents, and then reencrypts it using the public key from your server (mydomain.com) and forwards the request to the server, which then decrypts it and processes it.
Here is more information: http://en.wikipedia.org/wiki/HTTP_Secure
SSL offloading(https://f5.com/glossary/ssl-offloading) is also a feature used in network infrastructure for offloading the SSL load on other devices than web services. This is a form of man in the middle decryption of content. Also, Instrustion Detection systems in enterprise networks can have SSL certificates installed in them allowing these devices to decrypt the contents of requests and inspect them for behaviors indicative of network attacks.
I was requested to build a small server which supports SSL in .net which works well but I'm having trouble solving one issue. The server could be reached from multiple domain and also have multiple self signed certificates. But how do I know which certificate to serve to the client? Is there some way to know what domain a client used to connect to the server?
The client is also my own software which can be changed in case it's easier to add extra info in the client or something.
Edit: The problem I am talking about is called SNI (Server Name Indication) which is an extension of the TLS protocol and not supported in .net 4.5 as far as I can tell. Is there any way to use SNI in .net?
To clearify my situation I maintain both the client and server and therefore changes to both ends can be made.
This is my first post at stackoverflow.com, so if i do something wrong just let me know. So onto the problem.
I have a C# server currently running System.Net.Socket Sockets similar to the sample code Microsoft provided here.
I also have an Objective-C iPad client running NSInputStream/NSOutputStream bound to CFReadStream/CFWriteStream.
At present with only username/password authentication sent via an XML Serialized Object the client and server can communicate without any issues.
The problem I now have is that the communication has to be secure, and talking to clients, SSL encryption would be acceptable. However, I don't think they would accept just the "Server Certificate" as good enough. So I am trying to get the iPad client to use a "Client Certificate". I would like to enable true mutual authentication.
If I can't achieve mutual authentication, a third party VPN Software could be the better solution to secure the communication.
I haven't completed the conversion yet, but I have found a few articles that give me good examples of this, but there are no examples that fit my situation for client side certificates on the iPad.
The samples that i have found are:
C# SSL Tcp Server
Apple Developer site that shows how to use SSL, but no client certificate
iPad SSL Stream without client certificate.
iPad SSL Stream without client certificate
iPad HTTP Client that uses client certificate
Basically the system must eventually run TCP communication with SSL embedded with the ability to manage certificates. Not sure if it makes a difference, but as this would be going to many different clients, it is preferable to be compatible with SSL 3.0 and TLS(any version).
As I have only been dabbling in Objective-C for the past 6 months and am more familiar with C#, I will probably need you to explain your answer in simpler terms.
Edit:
I am more concerned with the Objective-C side of the equation, as I am fairly sure the C# side will be simple. Basically I need someone to explain how to implement client side certificates on a TCP NSStream in Objective-C or point me in the direction of possible solutions or approaches to the problem.
Any help will be greatly appreciated.
Chris
I cannot answer your question with regards to how to implement this on the objective-c side as what you ask is beyond what a single application can achieve on IOS devices. Thinking outside the box..
From Apple:
iOS supports the Simple Certificate Enrollment Protocol (SCEP). SCEP
is an Internet draft in the IETF, and is designed to provide a
simplified way of handling certificate distribution for large-scale
deployments. This enables over-the-air enrollment of identity
certificates to iPhone and iPad that can be used for authentication to
corporate services.
Knowing this and searching for SCEP in the developer library points me to this page - https://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/iPhoneOTAConfiguration/Introduction/Introduction.html
This page will be of interest, notice that Microsoft Server supports this:-
https://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/iPhoneOTAConfiguration/OTASecurity/OTASecurity.html#//apple_ref/doc/uid/TP40009505-CH3-SW1 and it even has some sample client/server code.
My interest is generally in the field of Mobile-Device-Management and have been looking into this.
Hope this helps.
Check out CFSocket and/or CkoSocket
BACKGROUND INFORMATION: PROGRAM WRITTEN IN C#
I'm working on a program right now that connects through a SOCKS5 proxy (coded from scratch. works well enough.), but I'd also like to (through that proxy) communicate to a DESTINATION through SSL.
I've done some research, googled many a time, and have come to the conclusion that SslStream won't be ideal for my situation. I NEED to first authenticate with the SSL through the proxy, and THEN start sending encrypted packets, once I receive the key.
QUESTIONS:
How can I encrypt my packets with TLS in C#? For some reason I can't at all figure it out. I'm stuck! :(
What is the raw syntax required to even REQUEST said SSL certificate?
You might want to have a look at the TLS implementation in the open source Bouncy Castle cryptography library. If it won't work as-is, you can hack it into doing what you need. If you want to deep-dive the specification itself, you'll find it as IETF RFC 5246.
As you've probably discovered, though, doing any portion of the connection setup work yourself leaves you with no way to use the WebRequest family of classes to handle the HTTP portion of the protocol work. That leaves you with two options I can see: do the HTTP yourself as well (I found a trivial example HTTP client floating around the net), or change the current user proxy server settings
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings]
"ProxyEnable"=dword:00000001
"ProxyServer"="socks=socks.example.net:1080"
then send the request normally using the WebRequest classes.
I'd like to offer you SSLBlackbox package of our SecureBlackbox product. Among numerous other components it has a simple SSL client component that is socket-based, can connect via different proxies (SOCKS, HTTPS CONNECT) and supports all features of SSL/TLS up to TLS 1.2. If you need more control, you can use any custom socket, and not just built-in socket support. This lets you use the components for securing traffic that goes not via sockets at all (pigeon mail can be secured this way as well).
An HTTPS client is available and included into SSLBlackbox as well.