When using C# and TCP, what is the best approach to let a client identify himself using a username and password and then allow multiple packets to be sent from the server to the client and from the client to the server without sending the username & password each time? Thread for each user? Token that's sent with each packet?
Also, how to make sure that only the client is able to read the data that the server is sending & vice versa? Just using SSLStream?
You are too low-level. What you need is an application protocol on top of TCP that supports authentication. One of the options may be HTTP. When working with .NET, the commonly used approach is leveraging WCF (Windows Communication Foundation). You can build a WCF service that will require authentication, such as “username and password” as you mention, while still being flexible about what underlying means of communication are used (e.g. SOAP and HTTP, or plain TCP and WCF's custom binary protocol, etc.).
Related
I have an old non-WCF Windows Service that creates a TCPClient to connect to a non-WCF TCP Server. I can't change the server app at all. It attempts to create a 2 threads, one for reading and processing messages from the Server, and one for reading from an MSMQ queue, processing, and then for sending to the TCP Server. Unfortunately, there are problems, and sometimes if there is a network disconnection I will get two instances of either the read or write threads. The threads share the same TCPClient connection.
Was hoping to switch my service to WCF, hosted by a Windows Service. I know I could use MSMQIntegration binding for a send method, but I am not sure how I could bind to a shared TCP connection. netTCPBinding seems to also be limited to WCF to WCF connections. Does anyone have suggestions on how to proceed?
This is theoretically possible with WCF's extensibility, but you would have to write a custom endpoint, a custom message formatter, and the fifty other classes. I'd recommend implementing the TCP service separately.
WCF Extensibility is best considered when you are dealing with a SOAP-like service which uses XML-like messages over a standard endpoint (transport). When you are "pretty close" to that, you can usually patch over the differences. When you are using none of that, WCF becomes a hindrance rather than a timesaver. For example, I would use WCF extensibility if:
I had a SOAP service which needed to run over SMTP or some other odd transport (custom endpoint)
I had a custom xml format that runs over a standard endpoint (I*MessageInspector)
I had a custom format which can be readily converted to XML running over a standard endpoint (custom message encoder)
I would not use WCF for:
Any format which does not convert readily to XML
Any format which does not readily identify the Action / target method
REST services (despite internal support - look at MVC Web API)
Anything requiring transport of large binary blobs (unless MTOM covers it)
Services where more than one of the built-in components have to be replaced
WCF library is the library that allows developers to communicate between WCF and non-WCF services in protocol agnostic way. Service developers using WCF don't need to known the details of protocol used between these services because these intricacies are hidden in WCF bindings. So the service developers have just to configure their client or server endpoints/bindings/behaviors correctly and these endpoints/bindings/behaviors do all the labor.
But WCF in not an universal platform to communicate with 'anything'. For instance NetTcpBinding uses TCP sockets to communicate. TCP protocol allows to create a pipeline between both parties but when this pipeline is established, TCP doesn't specify or mandate what content should be send through this pipeline. It can be some standardized protocol like HTTP, or proprietary custom protocol invented by SW developer that has never been published. There are hundreds maybe thousands of custom protocols that can flow through TCP including protocols like Modbus via TCP or IEC104. These 2 protocols for instance were specially designed to be tiny to communicate with the embedded devices and can't be used as the protocols for exchanging universal messages between Web services.
NetTcpBinding sends through TCP pipeline its own completely independent protocol designed by MS to provide efficient communication with WCF services build upon NetTcpBinding. It can't be used to communicate with your custom service using some unknown protocol with different (unknown) data serialization, timing, security, data exchange patterns, etc..
So the only viable option here is to use 'raw sockets' - classes like Socket or TcpClient to communicate with your proprietary service. But at first you must know what protocol your TCP Server is using. Maybe it's some standardized protocol like SOAP or HTTP or completely independent proprietary protocol that has never been published or documented.
And even though WCF has many extensibility options that allows developers to extend WCF library, these extensibility options are meant to be used when you want to allow WCF to communicate via other transport protocol (UDP, serial line, shared network path) or to add some new features to WCF bindings like new security option some extended transaction support or logging. But extending WCF to communicate with some non-WCF proprietary service (using some home-made protocol) would be inefficient (maybe impossible) and over-complicated.
So if your non-WCF service isn't using protocol that very close (virtually the same) as the protocol NetTcpBinding is using then WCF is not an option here. Use Socket or TcpClient classes.
I have created an SQL Server and a Client (c#) that directly queries the server. The problem is that I feel this is not secure, because every client (say 5 different clients in total) now has the connection string and i believe this is a crucial vulnerability.
What is the best way to create a back-end for an SQL Server running on my machine. This SQL Server will have to be accessible over the internet from various clients. Is the best option some C# application running with some library to interpret calls from the client?
It will be never secure if you allow your clients to CRUD without login, it is also unsecure if you pass your connection string to your client, if it is not necessary.
The better practice to implement a more secure backend application is you wrap actions into API (let's say UpdateClientInfo()), all database accesses go into the APIs and only allow your client to make use of the API. In this case your connection string will not be transferred via internet.
When the existing APIs are not suitable for your clients, kindly ask them to pull a request and implement the request, instead of providing the connection string to them.
It is also necessary to require the clients to provide user + password when they would like to access to your service.
There are many possible solutions. Exposing the database server is always a security risk. As you're obviously running on a Windows server I'd use a WCF service to handle the communication between the clients and the database.
It is also be possible to implement REST services in C#, which allows you to communication via ports 80 or (preferably) 443. That, depending on the firewall configuration, may be a good idea anyway, as it is a standard port which in most cases will be open for outgoing communication from the client side and can be enabled on the server side.
Look at existing APIs (for example for online shops, etc) to see how they group resources. This will help you design better APIs yourself.
What will be the best way, architecture, protocol, service etc
to implement a the following system:
a map server side written in c# and android client,
the client sends their location to the server and the server send to all clients location updates.
So far i investigated the following technologies:
REST and BusQueue.
is there something i am missing?
I am not aware of BusQueue.
The way I see it, is that the android client should send the updates to the server through http requests.
Now concerning the server, it depends on when the updates are required...if the android client requires the updates then again it should be an http request-response.
On the other hand if the server knows when the updates should be sent, you should consider using Google cloud messaging (more details here).
If you decide using cloud messaging you will have several implementation options, like:
Using messages with or without payload
Using http, or xmpp
Finally for the communication you could also check android libraries okhttp, retrofit and rabbitmq .
I'm programming an application that listens to ports for specific packets using REGEX. I can see the original TCP Stream, but I'm wondering if this is possible to intercept and stop this stream without any packet forging library.
Example:
A user navigates on a page where there is the word P*RN or "J*st** Bi*ber", and automatically, he loses this specific connection.
If I cannot do it, maybe I'll replace some HTMLElements on the fly.
You can implement a proxy server, so that all traffic from your users to the internet (and back) will go through your proxy. You can implement the proxy using the .NET networking API (no packet forging). When you want to drop the connection, you can either close the TCP stream, or send back an error response.
This solution has some problems too:
you have to implement specific proxy for each protocol you want to filter (SMTP, IMAP, POP3)
you need to force your users to use your proxy server when connecting to internet (this could be configured at network level)
it will not work with SSL (HTTPS), since the traffic is encrypted
Edit
I don't think there is a way how to intercept TCP streams using .NET API. However you can forward TCP streams (accepting client connection and then forwarding all communication between the client and the server). Since you accepted the client TCP connection, you can also terminate it.
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.