Want to have a ssl C# server that will only send and receive small JSON strings.
The clients can be anything from mobile devices or computers.
Need some feedback what to chose since some clients maybe have ssl limitations or other limitations.
Should i create an (openssl)ssl ftp socket server?
Should i create an HTTPs server?
should i create something else????
The HTTPS looks like easiest because of it's long history and width usage.
any feedback would be grate
Give a chance to WCF.
It has a very strong customizable stack, with externalizable configuration files, for both server and client side.
Moreover, it can publish services over multiples wires. This may help you to address a maximum of situations like "simple" https encryption to certificate validation.
You can even define your own channel for ultra specific contexts.
A last word from a developer perspective: the idea of WCF is to decouple the service from its connectivity. In today world, it's a huge advantage.
HTTPS is HTTP over SSL/TLS: you first establish an SSL/TLS connection and then you exchange HTTP requests and responses on top of it (as if it was a plain TCP connection).
Since you want to use SSL/TLS in both cases, what you seem to be asking is whether you should design your own protocol or use an existing one.
Should i create an (openssl)ssl ftp socket server?
There are multiple ways of securing FTP with SSL/TLS. It's certainly not the easiest way to go.
Should i create an HTTPs server? should i create something else????
Designing your own protocol means that you'll have to provide an implementation for each device yourself. HTTPS has the advantage of being widely supported. You shouldn't even have to use much of the underlying SSL/TLS API yourself (no need to learn the OpenSSL API). The only requirements might be to learn about some SSL/TLS configuration, such as setting up certificates.
Even if you're thinking of reducing the overhead due to the HTTP headers, your protocol will still have to perform similar payload management one way or another, at least to know where the requests and responses start and end.
It's unclear what your requirements are, but unless you really notice problems with HTTPS, exchanging JSON strings with HTTPS with an existing library (e.g. WCF) makes more sense than your other suggestions.
Related
I am currently working in socket based technology where my client(C++) and Server(.Net) uses
socket based communication to send and receive data,but now I am looking to replace my existing socket server with WCF. I want to clarify it completely before doing any such movement
1) Is it possible to replace existing socket and if yes how can I do this.
2) Server socket application listen at defined IP/Port and client socket application send request to that IP/Port only, but in case of WCF there is complete URI i.e. with IP/Port it also contains name of WCF Service, so how to do this.
3) Which type of binding configuration I need to use for it and if it is basic or wshttp can't it will effect performance of my application drastically.
When we use socket programming we do it at very low level and neither wcf, web service or remoting can perform good as compare to socket application. WCF provides so many feature but all this features are based on binding configuration and all this are at very high level as compare to socket application, so as far as performance is concern socket application will perform well as compare to wcf and if this are already build no need to replace it.
This is a rather difficult one to answer without knowing all the details of your application so I am going to attempt to answer this in a different order than you have asked it.
2) WCF supports multiple transport configuration. These are not limited to HTTP. For instance, the net.tcp transport doesn't use http at all but it does implement some complex functionality which you would need to replicate on the client side. For example Message Framing. This limits you choices to one of the standards-based approaches (unless you like doing that stuff).
3) Yes the http transports will probably be slower than direct socket communication. You will need need to profile exactly what features you require from WCF and what performance you need as there are many different configuration options which can have an impact on this.
1) So I guess this is the main answer. Yes it is possible but you will be required to make changes on both the client and server. While it is potentially possible for you to extend WCF to support your existing socket messaging format this could be a difficult and costly development process. Therefore you would want to implement this using Web Services (aka one of the http bindings) as opposed to net.tcp, msmq, etc.
Please note that WCF is actually extremely configurable with each layer having the ability to define custom transports, messaging, security, etc, etc. I would therefore suggest you read the documentation
We have a client/server system where all communications are done using a native protocol over a binary/SSL stream on TCP. All of our code is written in C# .NET 2.0 and some parts in 3.5. Our protocol is designed to support a variety of messaging patterns, namely Request/Response, and for lack of a better term, one-way messages from either the client or the server on an irregular basis.
Our objective is to add a feature to our system to carry our protocol over HTTP. There are several reasons for doing so, but I don't need to explain that here I think. Please tell me if I should.
The thought is to embed our protocol as application/binary in HTTP requests using the standard request methods ie., GET, PUT, POST, but not DELETE, and following the HTTP specification. This would be rather straight forward to do if our protocol was only request/response. The main concern comes from the one-way messages, and more specifically the unsolicited messages coming from the server. Another important concern is that HTTP is not oriented for persistent connections, but I believe with HTTP/1.1 this can be overcome. A third concern is that the server connections are not stateless.
We've been designing and prototyping this for a couple weeks, and we've come up with a couple ideas:
Refactor the code in the communication and protocol layers on both server and client sides. Although much of the code is shared, it is a lot of work that in all likely hood will not be a success. The question here is can this even be done with our poorly designed protocol?
Use a proxy approach. That is create an HTTP server using WCF and unwrap the HTTP messages and relay the native messages to and from our server over persistent connections. This would require a layer of abstraction on the client side that would actually maintain two connections to the proxy. One connection to perform request/response and the other to carry the unsolicited messages using a delayed response technique.
HTTP Tunneling which we haven't yet researched.
We're hoping that someone has encountered this challenge before and could lend some sound advice?
Please accept my apologies if this is the wrong place to post this question.
For the server initiated messages, you might consider WebSockets. According to Scott Guthrie's blog there is support for web sockets in ASP.Net MVC 4 beta.
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.
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.
As a part of a larger application I need to implement an SSL tunnel in C#. I was wondering if there's a better way of doing that instead of writing each step of SSL negotiation myself which sounds like reinventing the wheel.
Do you know if there are any libraries that I could use to minimize the code I need to write or any tutorials which show how this or similar thing can be implemented most efficiently in .NET?
SSlStream should do most of the work for you.
It's not clear what you mean by SSL tunnel. If I understand it right, you need some client-side software which acts as a local server (to which other applications connect), this software then connects using SSL to your server-side software, which in turn takes the data out of the SSL tunnel, and routes them further. In this case you would need client-side and server-side SSL/TLS components. You can use our SecureBlackbox for this task. SecureBlackbox provides comprehensive support for SSL/TLS protocol with complete control over connection and certificate management.
It can be that you need not plain SSL channel, but some kind of encrypting proxy. In this case you need to decide what exactly kind of proxy you want (will it be SOCKS proxy or HTTP CONNECT proxy) and implement it on the client side. one of the benefits of such proxy is that it can transfer the real connection address (i.e. where the client wants to go to) to the remote server, and that remote server will perform connection. This is more flexible approach, but it would require some (minimal, I should say) coding to implement the stuff, related to SOCKS or HTTP CONNECT request parsing and response generation.
.NET includes SSL support, centred around the System.Net.Security.SslStream class.