I invested practically a whole working day in figuring out how to approach the task mentioned in the title best.
Here is what I found out so far:
There's at least one library that offers TLS 1.2 for .NET CF out of the box. The downside: they charge for a license. In case someone's interested in this easy solution, Rebex Library
There are several SSL/TLS libraries out there that allow to communicate with the server on a lower level. My approach was to get to compile the BouncyCastle library for the .NET Compact Framework which I accomplished.
From here on out I found an article that showed me how to implement the BouncyCastle interfaces and how to put the pieces together. See Making HTTPS call in C# with the BouncyCastle library for more information. This is pretty much how my code looks right now.
I accomplished to establish a connection with the server and sent a request and I also got the expected response. I then wanted to leverage the HttpWebRequest class so I don't have to code the HTTP requests myself. Or so I thought. Not possible. HttpWebRequest doesn't have public constructors. Therefore I cannot inherit from that class.
I also tried using RestSharp for example but this is also only relying on the WebRequest class. Basically all the HTTP clients available out there take the Uri and then open a stream themselves. Not a single one seems to take an already open stream and writes to it or offers to drop in some crypto API to use instead of what the platform offers by default (other than the mentioned Rebex library of course).
So my question is: is there any HTTP client that can write HTTP commands to an already open stream or at least give me a string representation of what I set on it? Or do I have to really code something like that myself even though there's a ton of these implementations out there already? Or am I completely missing a point and it can be solved way easier?
Based upon your research, could you setup a kind of proxy within your CF app?
Use HttpWebRequest and response in the rest of your app, but direct them to your internal proxy (at 127.0.0.1).
The proxy would deal with the TLS connection, and then it uses a socket listener to intercept the HTTP requests from your HttpWebRequest, but is doesn't need to parse them out, just forward them along your already open socket. Likewise, return TCP traffic would be sent back from the real host and to the local socket (again it is not parsed, just treated as a buffer).
Related
I'm searching for a way of authentication like that from Blizzard (Authenticator). It creates an off-line OTP.
I know that larger companies use it as "tokens" however, I'm still unable to find a proper library.
So, what I want;
A project that is able to create OTPs on the client side without having the client to connect to the internet and yet be able to generate the exact same on the servers-side.
I think you can take a look at this library: https://code.google.com/p/otpnet/
It is a C# port of a popular TOTP/HOTP for PHP. There seems to be a few outstanding issues in the library which have not yet been fixed by the developers but you can easily patch it on your side with recommendations that have already been submitted.
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'm building an application (both client and sever sides) that may need to send and receive data over the network. The messages will be short, and probably mostly binary. I need the connection to be secure even on public networks.
I'm not looking to reinvent the wheel, so I'd love if the protocol would handle all session-management overhead itself (handshake, dealing with dropped packets, sending back ACK responses, etc.). It will also be nice if it'd be naturally supported in Windows, Linux and OS X (by the .net framework, and the *NIX kernels).
So far, I've considered several options:
HTTPS - has good support for all of the above, except for the overhead. If the message is short, all the HTTP headers are just redundant. Natively supported.
IPSEC - is supported natively, but forcing me to handle the session myself.
Google's Protocol Buffers over HTTPS - the best option for now, but requires some implementation effort.
I'm new to the world of network programming, so any advice or tip would be greatly appreciated.
I think you'll first have to decide at what level you want to work. IPSEC as a protocol works at about the same level as IP; basically, you'll have to do everything yourself. HTTPS is a significantly higher-level protocol.
HTTP/HTTPS is universally supported, (with a little bit of work) will work through proxies etc. HTTPS gives you privacy and optionally authentication of the endpoints, at little extra cost. The operating system might even already provide a key store which you can use.
You can also open a socket and simply push encrypted data back and forth; think telnet or SSH (although SSH is fairly heavyweight during the protocol negotiation phase). Encryption libraries are available in or for most frameworks, but you have to be careful with key management and exchange. If you can live with using pre-shared keys, though, this is not necessarily a problem at all, really; otherwise, X509 certificates might be a workable approach that is readily supported on many platforms.
IPSec works on IP level, and it's used to secure network connections on system level. It's not usable on application level. So SSL/TLS is the best option as being the most popular and natively supported etc. If you want to use UDP, there exists DTLS protocol (TLS over UDP), but it's not as widely supported as regular TLS.
If you don't want to deal with sockets at all and prefer to focus on business logic, take a look at our MsgConnect product. This is a lightweight cross-platform message-oriented middleware, which lets you send and receive messages and MsgConnect will deal with sockets itself.
I'm working with asp.net MVC. Now I don't know how to send data form a server (using asp.net ) to another server using (win32 console command line). Plz help me.
P/S: Is there any security hole in this method.
Well generally the case is that most ports today are blocked behind firewalls so setting something like that up with winsock, is outdated. If you are tring to connect two servers there are many options, You could look into the System.Web.WebClient,System.Net.HttpWebRequest,Microsoft's Sync Framework, Rhino queues but heres the run down on the first two.
In short, HttpWebRequest gives you more fine grained control over your
request. WebClient does not. It encapsulates most of the stuff for you.
WebClient is very useful if you want to do specialized, one-off tasks, eg:
download file, do forms post etc.
HttpWebRequest is useful if you want to do more complicated stuff.
The WebClient is especically simplified, we can use it's DownloadData,
DownLoadFile to retreive file/stream from remote webserver. Here are some
tech articles and resources describing using webclient or webrequest:
Hosting WCF services, WebClient
here
and webrequest here.
You have two servers trying to communicate. If you are going to use IP (I am assuming you will since you mentioned Winsock) you must choose between these two protocols:
TCP
UDP
Once you've decided which one to use, you can write a server process (the console application) that listen to a specific port (TCP or UDP port depending on what you've chosen) that will serve your client process (the ASP.NET application).
If you use TCP/IP, you use sockets to communicate. If you use UDP/IP, you will send and receive independent packets.
Here is a TCP/IP client/server code sample in C# you can use. You will wrap and run the client portion of this example is a class you can access within ASP.NET MVC.
Here is a UDP/IP server code sample in C#.
Regarding your question of the security of this approach, the question does not provide enough information to answer it properly. You will need to provide more information.
I would like to have a client-server application written in .NET which would do following:
server is running Linux
on the server there is SQL database (mySQL) containing document URLs
What we want:
- server side would regularly crawl all URLs and create a full text index for them
- client side would be able to perform a query into this index using GUI
The client application is written in .NET using C#. Besides of searching in documents it will be able to do a lot of other things which are not described here and which are done client-side very well.
We would like to use C# for the server side as well, but we have no experience in this area. How are things like this usually done?
Clarifying question now based on some answers:
The thing which is most unclear to me is how client-server communication is usually handled. Is client and server usually using sockets, caring about details like IP addresses, ports or NAT traversal? Or are there some common frameworks and patters, which would make this transparent, and make client-server messaging or procedure calling easy? Any examples or good starting points for this? Are there some common techniques how to handle the fact a single server is required to server multiple clients at the same time?
To use c# on Linux you will need to use Mono. This is an open source implementation of the CLR specification.
Next you need to decide on how to communicate between server and client, from the lowest level of just opening a TCP/IP socket and sending bits up and down, to .Net remoting, to WCF, to exposing webservices on the server. I do not know how compleat WCF implementation is on mono, also I think you may have issue with binary remoting between mono and MS .Net .
I would suggest RPC style WebServices offer a very good solution. WebServices also have the advantage of alowing clients from other platforms to connect easily.
EDIT
In response to the clarification of the question.
I would suggest using mono/ASP.NET/WebServices on the server, if you wish to use c# on both server and client.
One assumption I have made is that you can do a client pull model, where every message is initiated by the client. Using another approach could allow the server to push events to the client. Given the client has the ability to pole the server regularly I don't consider this much of a draw back but it may be depending on the type of application you are developing.
Mono allow execution of c# (compiled to IL) on a Linux box. Mono ASP.NET allows you to use the standard ASP.NET and integrate into Apache see http://www.mono-project.com/ASP.NET and finally WebServices allow you to communicate robustly in a strongly typed manner between you client and your server.
Using this approach negates most of the issues raised in your clarification and makes them someone else's problem.
Sockets/SSL - is taken care of by standard .Net runtime on the client and Apache on the server.
IPAddress/ports/NAT traversal - Is all taken care of. DNS look up will get the servers IP. Open socket will allow the server to respond through any firewall and NAT setup.
Multiple Clients - Apache is built to handle multiple clients processing at the same time as is ASP.NET, so you should not encounter any problems there.
As many have already mentioned there are a number of thing that you have mentioned which are going to cause you pain. I'm not going to go into those, instead I will answer your original question about communication.
The current popular choice in this kind of communication is web services. These allow you to make remote calls using the HTTP protocol, and encoding the requests and responses in XML. While this method has its critics I have found it incredibly simple to get up and running, and works fine for nearly all applications.
The .NET framework has built in support for web services which can definitely be called by your client. A brief look at the mono website indicates that it has support for web services also, so writing your server in C# and running it under mono should be fine. Googling for "C# Web Service Tutorial" shows many sites which have information about how to get started, here is a random pick from those results:
http://www.codeguru.com/Csharp/Csharp/cs_webservices/tutorials/article.php/c5477
have a look at Grasshopper:
"With Grasshopper, you can use your favorite development environment from Microsoft® to deploy applications on Java-enabled platforms such as Linux"
Or see here
The ideea is to convert your app to Java and then run it on Tomcat or JBoss.
Another approach: use the Mod_AspDotNet module for Apache, as described here.
This Basic Client/Server Chat Application in C# looks like a kind of example which might be a starting point for me. Relevant .NET classes are TcpClient and TcpListener