We need to Implement one way ssL connection to a remote server . We have been given the APi end point and also the public key certificate.
We are trying to use the HttpClient to connect but it seems this approach requires us to have a private key as well.
Is there an example one way SSL implementation example in .net that we can refer
Related
I'm currently developing a C# application that communicates between a client and server using TCP/IP. After connecting I'm swapping session based RSA public keys to then pass a session based AES symmetrical key. This all works fine and means I have a secure channel to communicate on.
The trouble now is that I need to ensure that the server and client are both the ones I wish to communicate with. Before anyone suggests SSL/TLS: I'm not connected to the Internet to allow the use of a root CA.
Would it be valid, that after establishing a secure channel between the client and server that I provide a simple challenge-response method? For example, if the client sends an identifier (GUID?) the server compares this value to known clients and accepts or rejects it, and the same is repeated in the opposite direction. As the data is encrypted and the encryption is session based is this a valid method of verification?
I understand that the storage of these identifiers is the weak point.
Before anyone suggests SSL/TLS: I'm not connected to the Internet to allow the use of a root CA.
Before you are re-inventing the wheel: you don't need root CA with SSL/TLS but can simply use self-signed certificates with key pinning. Public root CAs are only usually used because it scales much better to provide only few common CAs instead of exchanging all self-signed certificates (or their fingerprint) to all peers of the communication.
Apart from that it looks like you proposal assumes a secure connection already to check credentials which you then will use to verify that the connection is really secure. Or in short: to provide a secure connection you need a secure connection first.
I am currently looking for the best way to establish a stateful and encrypted connection between a C# client and server application. First, I thought about using IPsec, but as it works on a low level (OSI: Internet Layer), I would be very hard to implement, if you want the functionality inside your program and don't want to rely on the OS.
What technologies would you recommend for this purpose? Is there some functionality already built into .NET (4.5)? It does not neccessarily have to be stateful, working with some kind of heartbeat would be a valid option, too.
You'll want to use a standard protocol such as SSL rather than trying to make your own. First the implementation will be much easier because the .NET framework will support it, and the transport protocol that runs underneath it is stateful (e.g. TCP). Second developing a cryptographic protocol that is secure is very difficult, and SSL has already been implemented so why reinvent the wheel?
SSL works by using PKI (Public Key Infrastructure) to generate a shared symmetric key. The handshake consists of a number of steps. First the client sends a request for a secure session, then the server responds with it's certificate, the client verifies the certificate by crawling up the ladder through the certificate authorities (e.g. Verisign, Thawte, GeoTrust etc...) or if it already trusts the server it can just accept the certificate that is self signed.... and once it finds the certificate is trustworthy it generates a symmetric key and picks an algorithm (e.g. AES, 3DES, RC4, IDEA etc...). The client then encrypts the key and algorithm being used with the public key, then the client sends that value to the server and a secure session can proceed using symmetric encryption which is much faster.
SSL itself is can be used in a stateful manner because it actually works over the transport layer in the OSI Model, HTTPS on the other hand is not a stateful protocol by design. HTTPS is HTTP over SSL so the two technically don't really have anything to do with each other, except that in HTTPS SSL is used to secure the application data that is being requested. With HTTPS as with HTTP once a request is made to the server it basically forgets about you (not exactly how it happens but for all intents and purposes you can think of it this way). I myself would prefer the use of HTTPS if you can get around having to have a stateful protocol. The main reason for doing so is so that I wouldn't have to write the code and possibly have a mistake in the implementation of SSL. All you have to do is build a WCF or REST based service that runs on IIS and get a certificate for your server.
That being said, if you still want to create your own SSL server that doesn't use HTTP on the application level you can use the TcpListener and TcpClient classes along with the SslStream class provided as part of .NET to create your own. MSDN has a good example of how to create an SSL server and client: http://msdn.microsoft.com/en-us/library/system.net.security.sslstream%28v=vs.110%29.aspx
Side Notes
Securing the transport of your data does not secure your app, do not make the mistake of thinking you get automatic security
If you choose to make your own server and client you can use either openssl to generate your certificate or you can use makecert which is part of .NET to make your certificate.
Just form a regular TCP connection between the applications, and write up a simple packet protocol (EG, 4 bytes indicate packet size, followed by packet data)
Except the data within this base-level packet is encrypted through System.Cryptography.AesManaged
If you have trouble encrypting the packets using AesManaged, try using The Encryptamajig - if that doesn't help, post further questions and we'll give you further specific help.
-- You can either have both sides know the password ahead of time (EG, tell the person at the other end the password in person), or quickly pass it unencrypted at the start of the connection (or, rather, encrypted with a default known password)
Not necessarily the best method but it should do the job.
Why not just the regular HTTPS? HTTP is just one level above TCP but it is far easier to work with and firewalls tend to be generally easy on HTTP/HTTPS ports namely 80 and 443. Of course, plain HTTP is not suitable for you but can you not use HTTPS instead of coming up with your own encrypted communication mechanism? In the client side (C#), all .NET classes such as HttpClient supports HTTPS very well. I quote Ayende in support of my suggestion to go with HTTP :)
I want to add some security to a client(iPhone) - server(c#) application I'm working on, mainly to encrypt messages sent between client and server.
I know i should use SSL but not really sure what the steps i need to do in both client and server to implement it.
Can someone please give me some guidance?
I don't use HTTP protocol, i use my own textual protocol, but any way with HTTP or my own protocol how do i add ssl support? i know that in c# there is SSLStream instead of regular Stream. And on ios there is some stream settings i need to configure, i just don't know how to do it.
Host the application using SSL in IIS, then use HTTPS as the service point. [edit] Don't forget you'll need a cert.
Take the easy approach, which is allowed to go on the App Store without having to go through all the encryption law stuff. Simply use a HTTP server and a client.
C# runs the HTTP server (maybe use IIS to handle that? Maybe C# has its own software for that) and the iPhone simply uses NSURLRequest.
Easy to implement and safe, since you'll benefit from patches from Apple and Microsoft.
Update for the updated question: I did some quick research and this kept popping up: kCFStreamPropertySSLSettings - maybe it helps you. It's apparently something for NSStream that allows it to create SSL connections, or something. I'm afraid I can't help you more than that.
I'am implementing a SSL server in C#, using standard SSLStream.
Everything is fine so far, but - AuthenticateAsServer accepts only single certificate as parameter, while I have to provide the complete chain (3 of them).
I've built PKCS12 struct with all certificates (with help of Mono.Security), then call new X509Certificate2(pkcs12.GetBytes()), but nevertheless, only one is presented to the client.
So, the question is - how this could be done?
Thanks!
PS: I need a portable solution, which will work both in Mono and .NET on Windows.
Your setup is correct. The web server uses only one certificate with the SslStream (or anything else).
The certificate might be missing some information : The Authority Information Access extension of your server certificate shall point to the URI where the intermediary certificate will be downloaded.
Is this information missing ?
I'm writing a client/server application that requires the server needs to be able to authenticate the client and also requires all comms to be encrypted.
The mechanism to provide this needs to be self contained within the server and client application and also to be fully automated (no human interaction required). SSL seems to be the best way to do this and is also something I am familiar with using.
For each client that needs the client software deploying to it, I planned to create (on the fly) an MSI installer with the application, the clients certificate (signed by the server) and private key and the servers public certificate (so the clients can authenticate the server - the server certificate could be self signed).
I can generate the key for the client and make a CSR, but don't seem to be able to find a way of actually signing the CSR and generating a certificate for the client thou. I have looked into the Win32 Crypto API, but haven't managed to find any examples of how to actually sign a CSR and get a client certificate.
I know how to do all of this from the command line with the openssl tool, but am not sure of how to do it from within an application.
Please note that making system calls out to the openssl tool and passing in the parameters I know to work is not an option as it's a huge security risk to rely on the openssl tool not being compromised in any way. Doing it this way wouldn't for fill the self contained requirement.
I am going about this the right way, or is there a better way to achieve the same thing - basically authentication of the clients connecting to the server and a way of the connecting client to authenticate the server they connect to, all encrypted.
I cannot make any assumptions about the server (or clients) having a static IP or hostname (DNS can be broken anyways), nor can I make any assumptions about any existing PKI infrastructure.
I am writing this primarily in C#.Net, but would consider writing a C++ extension to this if it gives me this functionality.
Finally this is my first post here, so if I've missed out something obvious or have been short on any details, please ask and I'll fill in the gaps :)
Thanks,
James
In C# you can use PKIBlackbox package of our SecureBlackbox product which provides all the functionality you are looking for in .NET. Maybe BouncyCastle library also includes this functionality.
You need to rethink at least part of this. What you are doing is radically insecure. The client's private key needs to be generated at the client. Otherwise it isn't private, so it cannot possibly satisfy any of the tenets of PKI,. including the purpose for which you are issuing it. You lose uniqueness and you also lose non-repudiability. These are both fatal flaws.