What i want to do is to parse the method-type of a HTTPS message using wireshark.
I saw that for a HTTP message I see that for a 'GET' message, on the first row I see 'Get ...'.
Now I want to check the same for a HTTPS message, but I dont see any field flagging the method-type.
What am I missing?
HTTPS is HTTP inside a SSL tunnel. So you need to first decrypt the data of the SSL tunnel before you could find out which method is used. Unless you can get access to the keys of the encryption there is no way to decode the content and get at the HTTP traffic.
HTTPS is HTTP over SSL. The entire HTTP request is encrypted as SSL record and that is what the server receives. And server/client reach this stage only on setting up the SSL tunnel successfully. You need to invoke appropriate methods to unwrap the SSL layer and get the application data.
I assume you are trying to decode it from Wireshark. You will need to posses the server's private key to get the data out. Wireshark has the means to load the key. It shall then display the decrypted data in the capture. - http://support.citrix.com/article/CTX116557
Related
When a web server receives a http(s) GET request from a client, it has access to some information such as:
The client IP
The request itself :
the headers (including the cookies)
the content
and... that's all ?
I am wondering if there is something else.
Indeed, I am trying to make a server that can access to a page where it can collect some information to update its database. The site denied access to my server but not to web browsers, even if I replicate the IP, the headers and the content.
Thanks for your help.
Yes, it's only what is contained in the request itself. The server cannot reach back to the client to "pull" information, it only has the information contained in the HTTP request and the underlying TCP/IP packet. That's:
the requesting IP address
the HTTP headers, including requested URL and HTTP method
the HTTP request body, if any
if it's HTTPS, any data exchanged during the TLS handshake, which is usually not very relevant for identifying anything significant
All of that information is voluntarily provided by the requesting client.
I have a general networking question but it's related with security aspect.
Here is my case: I have a host which is infected by a malware. The malware creates an http packet to communicate with it's command and control server. While constructing the packet, the IP layer contains the correct IP address of the command and control server. The tcp layer contains the correct port number 80.
Before sending the packet out, the malware modifies the http header to replace the host header with “google.com" instead of it's server address. It then attaches the stolen data with the packet and sends it out.
My understanding is that the packet will get delivered to the correct server because the routing will happen based on the IP.
But can I host a webserver on this IP that would receive all packets with header host google.com and parse it correctly?
Based on my reading on the internet, it is possible but if it is that easy then why have malware authors not adopted this technique to spoof the http headers and bypass traditional domain whitelisting engines.
When you make a request to let's say Apache2 server, what actually Apache does is match your "Host" header with any VirtualHost within server's configuration. Only if it cannot be found / is invalid, Apache will route the request to default virtualhost if it's defined. Basically nothing stops you from changing these headers.
You can simply test it by editing your hosts file and pointing google.com to any other IP - you will be able to handle the google.com domain on your server, but only you will be to use it this way - no one else.
Anything you send inside HTTP headers shouldn't be trusted - it just a guide for your server on how to actually handle the traffic.
The fake host header is just there to trick some deep-inspection firewalls ("it's for Google? you may pass..."). The server on that IP either doesn't care about the host header (default vhost) or is explicitly configured to accept it.
Passing the loot on by using fake headers or just as plain data behind the headers is another trick to fool data loss prevention.
These methods can mislead shallow application-layer inspection but won't pass a decent firewall.
I am curious to know the difference between the data sent over a HTTP connection and over HTTPS connection. I mean, what is the content, how it looks like in both cases. I am able for find for HTTP, but what is the corresponding content if same information is shared over HTTPS? HTTP contains Request Line, Header and Message body. I hope difference will be wrt Message body. Can anyone explain? Certificate content is embedded in this Message body or how is it?
In HTTPS (HTTP over SSL) the HTTP request is performed over a SSL tunel, hence both the HTTP headers and the payload are encrypted.
The certificate is sent by the server when the connection is established, as part of the TLS handshake. Such certificate must be trusted by either the client itself or a party that the client trusts.
Probably this article will give you a better understanding of the handshake.
I am curious to know the difference between the data sent over a HTTP connection and over HTTPS connection.
There is no difference.
I mean, what is the content, how it looks like in both cases.
It is the same in both cases.
I am able for find for HTTP, but what is the corresponding content if same information is shared over HTTPS?
It is the same.
HTTP contains Request Line, Header and Message body.
And so does HTTPS.
I hope difference will be wrt Message body.
The difference is in the fac that the entire payload is encrypted.
Can anyone explain?
I have endeavoured to do so.
Certificate content is embedded in this Message body
No.
or how is it?
It is embedded in the TLS handshake, which precedes any data exchange over the connection, including the entirety of any HTTP content.
I'm able to make HTTP requests on my local host using client certificates.
I have some logic in my code that can make two requests use the same certificate for their requests, or not, depending on certain conditions.
My localhost is currently pointing to the default 'Welcome to IIS' page.
Is there any way to use Wireshark to detect if the client certificates that are being sent from my machine in separate requests are the same or not?
PS: If someone can suggest a better way of achieving what I'm trying to do here, that'd work as well. I don't necessarily need to use Wireshark. My main objective is to figure if two different requests are sending the same cert or not, as I've mentioned here:
How do I monitor client certs that are being sent via the requests?
Thanks!
I found a way to do this. This guide helped, in summary, yes, you can use Wireshark to examine what client certificates are being sent from the client (or received on the server).
You need to start capturing traffic on Wireshark, only for the period of time when the request(s) is made and processed, and then add the appropriate filters to filter based on the protocol. In my case, I filtered it based on the IP address of the sender and receiver because I knew both.
You'll need the server's certificate to decrypt the messages because they'll be transmitted in encrypted format. You can easily do that by going to Edit -> Preferences. Select Protocols from the menu on the left -> SSL -> Click edit. Add the server's cert and IP, and save the settings.
when we use https.........for example to send login credentials(https://example.com?username=aaaa&password=aaaa123). HTTPS encrypts the data using SSL certificate. So the url will be encrypted string. I am giving two requests with the same url(https://example.com?username=aaaa&password=aaaa123). On every request the url will be encrypted. Will the encrypted url of the first request be same as the encrypted url of the second request? Is the SSL certificate going to be different everytime btween client and server?
Thanks,
Iqbal
Will the encrypted url of the first request be same as the encrypted url of the second request?
The URL will be the same, because you said so. If you're asking whether the encryption of the URL will be different, the question is meaningless. It's impossible for anyone to tell, because the entire request is encrypted, so it is impossible to pick out the part that consists of the encrypted URL.
Is the SSL certificate going to be different everytime btween client and server?
The SSL certificate is the same for the entire SSL session, which persists beyond the current connection for as long as both client and server remember it.