I'm writing a server which is accepting incoming TCP connections and I would like to implement a simple way in C to detect if connection is SSL just inspecting few received bytes. Any help?
It is possible since the first message after the connection is established should be a "hello" message from the client. The first field in the message is the SSL/TLS version, then a timestamp follows - depending on the application layer protocol a plain client uses, this may be enough to figure out if the client connecting uses SSL/TLS or not.
See https://www.rfc-editor.org/rfc/rfc5246#section-7.4 for more details on the message structure.
Edit: here's a very similar question with an excellent answer: https://security.stackexchange.com/questions/34780/checking-client-hello-for-https-classification
Related
I'm trying to create a bridge in C Language that uses two protocols : OPC-UA and MODBUS.
Between the client and the bridge I used the protocol open62541 to ask for some data of any type. When the bridge receive the request, the memory requests start, from the brigde with the protocol MODBUS, to the MODBUS server, that should send back those memory variable asked.
My problem is that I cannot find any way to see the point in the code, where the Server recieve the Client request.
I need to find how to send those memory variables back from the server to the Client.
I would be glad if someone has the solution.
By guessing I assume you mean a ReadRequest and you want to find out where this read request is handled in the server?
It could be this one: Service_Read
https://github.com/open62541/open62541/blob/71e9a44d1aec5bc0cce465c8daefe47883b25f6c/src/server/ua_services_attribute.c#L394
Or also the Operation_Read:
https://github.com/open62541/open62541/blob/71e9a44d1aec5bc0cce465c8daefe47883b25f6c/src/server/ua_services_attribute.c#L394
you are looking for?!
I searched and found no answer for this so thought it is worth asking here.
I have made my client-server(SQL Server) connection secured.It is working fine but whenever i am checking the data packets by using netmon tool i am seeing TCP protocols also along with TLS.
If the channel is secure then i should not expect TCP.It shhoud only show TLS.
Please have a look on screenshot below :
Any comment would be appreciated.
Thanks
I couldn't find a resource better explaining it but these ones:
https://msdn.microsoft.com/en-us/library/bb879935(v=sql.110).aspx
https://technet.microsoft.com/en-us/library/bb879919(v=sql.110).aspx
implicitly try to say that whether you use only SSL or both SSL and non-SSL, the first connection will be made over the default TCP port. Afterwards, if the client requests an SSL connection, then the SSL connection will get started in addition to the default TCP.
By the way, I don't know if netmon is capable of but you can try using WireShark and looking inside those TCP packets to understand better what's going on maybe.
I am trying to do a web server that will provide a set of questions (poll) to the users trying to connect to it.
The only issue is that I do not want to send everyone the questions, I would like to choose which connections to accept. (for example, a simple algorithm that chooses only even numbered connections, in the order they connect). To the other ones I would send a message saying you have not been picked.
I am using select() function to handle multiple connections.
Any ideas on how I can choose this? Good to mention that I am doing this in C language.
You can not skip a connection without accepting it, as they are queued by TCP protocol stack. What you'd have to do is to accept the connection, send an error message and than close the connection.
There's something that bothers me: I'd like to distinguish between a packet coming from Youtube and a packet coming from Wikipedia: they both travel on HTTPS and they both come from the port 443.
Since they travel on HTTPS, their payload is not understandable and I can't do a full Deep Packet Inspection: I can only look at Ethernet, IP and TCP struct headers. I may look at the IP address source of both packets and see where they actually come from, but to know if they are from Youtube or Wikipedia I should already know the IP addresses of these two sites.
What I'm trying to figure out is a way to tell from a streaming over HTTP (like Youtube does) and a simple HTML transport (Wikipedia) without investigating the payload.
Edit 1: in a Wireshark session started during a reproducing video I got tons of packets. Maybe I should start looking at the timeout between packets coming from the same address.
If you are just interested in following the data stream in Wireshark you can use the TCP stream index, filter would be something like tcp.stream == 12
The stream index starts at zero with the first stream that wireshark encounters and increments for each new stream (persistent connection).
So two different streams between the same IPs would have two different numbers. For example a video stream might be 12 and an audio stream, between the same IP addresses, might be 13.
If you started the capture before the stream was initiated you'll be able to see the original traffic setting up the SSL connection (much of this is in clear text)
You may consider looking at the server certificate. It will tell you whether it's youtube (google) or facebook.
That would give you an idea whether SSL connection is to youtube, which one is to facebook.
You can try looking at the TCP header options, but generally the traffic is encrypted for a reason... so that it wouldn't be seen by man-in-the-middle. If it were possible, it would be, by definition, a poor encryption standard. Since you have the capture and all the information known to the user agent, you are not "in-the-middle". But you will need to use the user agent info to do the decryption before you can really see inside the stream.
this link: Reverse ip, find domain names on ip address
indicates several methods.
Suggest running nslookup on the IP from within a C program.
And remembering that address/ip values can be nested within the data of the packet, it may (probably will) take some investigation of the packet data to get to the originator of the packet
Well, you have encountered a dilema. How to get the info users are interchanging with their servers when they have explicitly encrypted the information to get anonymity. The quick response is you can't. But only if you can penetrate on the SSL connection you'll get more information.
Even the SSL certificate interchanged between server and client will be of not help, as it only identifies the server (and not the virtual host you'll try behind this connecton), and more than one SSL server (with the feature known as HTTP virtual host) several servers can be listening for connections on the same port of the same address.
SSL parameters are negotiated just after connection, and virtual server is normally selected with the Host http header field of the request (see RFC-2616) but these ocurr after the SSL negotiation has been finished, so you don't have access to them.
The only thing you can do for sure is to try to identify connections for youtube by the amounts and connection patterns this kind of traffic exhibit.
There's already a question How exactly does a remote program like team viewer work which gives a basic description, but I'm interested in how the comms works once the client has registered with the server. If the client is behind a NAT then it won't have its own IP address so how can the server (or another client) send a message to it? Or does the client just keep polling the server to see if its got any requests?
Are there any open source equivalents of LogMeIn or TeamViewer?
The simplest and most reliable way (although not always the most efficient) is to have each client make an outgoing TCP connection to a well-known server somewhere and keep that connection open. As long as the TCP connection is open, data can pass over that TCP connection in either direction at any time. It appears that both LogMeIn and TeamViewer use this method, at least as a fall-back. The main drawbacks for this technique are that all data has to pass through a TeamViewer/LogMeIn company server (which can become a bottleneck), and that TCP doesn't handle dropped packets very well -- it will stall and wait for the dropped packets to be resent, rather than giving up on them and sending newer data instead.
The other technique that they can sometimes use (in order to get better performance) is UDP hole-punching. That technique relies on the fact that many firewalls will accept incoming UDP packets from remote hosts that the firewalled-host has recently sent an outgoing UDP packet to. Given that, the TeamViewer/LogMeIn company's server can tell both clients to send an outgoing packet to the IP address of the other client's firewall, and after that (hopefully) each firewall will accept UDP packets from the other client's Internet-facing IP address. This doesn't always work, though, since different firewalls work in different ways and may not include the aforementioned UDP-allowing logic.