Say user makes a request (get|post) to http://example.com/data
now i've server setup, nginx, to redirect all requests to https.
so browser again sends a request but via https protocol.
my question is did server tell browser to redirect right after reading http headers or it could have gotten data in body of request and then told browser please send this via https.
because if latter, sensitive data has already been sent via insecure method.
I understand to prevent this i can include redirection in html file, are there any other methods.
It doesn't matter if the server reads it, because the client might have sent it anyway.
At the time when the server has finished reading the headers, the client has already sent the headers (obviously) but it also has sent some or all of the body.
How much of the body has been sent by the client is not dependent on HTTP, but on the underlying TCP protocol. It is dictated by variables such as the receive window, the congestion window and the size of the headers and of the body.
See this great article for an explanation about congestion/receive windows in TCP.
Related
I have a Nodejs server that communicates via a REST API with HTTP. I would like now to change the protocol of transmission of all my requests from HTTP to HTTPS. The problem is that I cannot change the client code.
I would like to know if redirecting all HTTP request on the server to https is enough to have the data sent with encryption. Or if I must modify the code that runs on the client and that makes the request with HTTP protocol.
I have to do it because the data should not be sent in clear as there are some sensitive data that are sent (username, password, position information).
Thanks.
The purpose of using HTTPS is not just encryption. It also provides authentication of the server to the client, among others.
One problem with having a client that makes plain http requests (regardless of then being redirected) is that an attacker may create a fake server, to which the client would talk to, revealing secrets or pulling fake data. Without requests being made over https initially, there is nothing to stop an attacker from doing this.
Even worse, an attacker can just listen in to traffic to the real server. If a man-in-the-middle attack is possible (like for example the attacker is on the same local network as either the client or the server), the attacker can hijack the initial plaintext request, talk on HTTPS to the API, then respond on plain http to the client, and so on, for all requests. From the client's perspective, it "just works", from the server's perspective, it's all good, on https.
This is called SSL Stripping.
So the only solution is to have the client do all requests (including the first one) over https. One way to ensure this with browser clients is to use the Strict-Transport-Security (HSTS) response header. For non-browser clients, you can implement them to either comply with HSTS or simply make all requests over https.
I'm using the request module to send http requests from my server.
I want to be able to intercept the request before it is sent and save it as a raw http request text.
There are GUI tools such as burp suite that will act as a proxy server and intercept outgoing requests in raw HTTP text, but I need to be able to do this in my node server.
So far my efforts to convert a request object to raw string has been futile and I'm pretty sure there are better ways to do so but I'm stuck.
Thanks
Currently, we plan to send a short, and sensitive to a server using GET method. We will append the information, in the GET request string.
We are going to use https.
I was wondering, is there any need for us to perform AES encryption on the data (No decryption needed at received server side. Hence, transferring encryption key over server is not a requirement), before we append it in GET request string?
Is an attacker able to sniff the GET request string, if https is being used?
No, the attacker won't see the GET request string if HTTPS is used.
The TLS/SSL layer gets setup before any of the HTTP traffic is sent across.
If you allow HTTP connections that then immediately forward to HTTPS connections, the GET request will be available in the clear. If you keep HTTPS the entire time, it won't.
That said, there are other reasons not to do this, such as the sensitive data being potentially available in the Web Server access logs.
Here are some similar Q/A threads that will give a good background on the topic:
Is an HTTPS query string secure?
HTTPS, URL path, and query string
Are querystring parameters secure in HTTPS (HTTP + SSL)?
I need to solve an issue where the HTTP post data is unencrypted in memory for a few seconds before proxying it onto the next server. Let me explain.
In a browser a user enters form data. Sensitive form data.
The browser has an SSL connection to the HTTP server. The HTTP Server has an SSL connection to the back end server. My understanding is that the SSL Connection terminates between each server. Therefore the HTTP Post contents are decrypted when it gets to the HTTP server. The HTTP server or better defined the transport layer then re-encrypts the data before sending to the end server.
The issue here which our customer has asked us to solve is to prevent the clear form data from existing in between receiving the data and sending the data to the back end server. It is a little pedantic but its not my requirement. I'm just trying to solve it.
Many thanks.
The data isn't unencrypted if it is being proxied it is still being encrypted to the endpoint (end server). Or maybe I am misunderstanding you.
Would like to understand whether the HTTPS body part of the Response is encrypted. Also, in a HTTPS request whether the header are transmitted as plain text / encrypted?
Is there any tool with which I can observe the raw HTTPS traffic without decrypting it.
HTTPS is HTTP over SSL. So the whole HTTP communication is encrypted.
As the other posts say - HTTPS is HTTP (plaintext) wrapped in SSL on top of the TCP/IP layer. Every part of the HTTP message is encrypted. So the stack looks like:
TCP/IP
SSL
HTTP
As far as encryption goes, there is no way to see any part of the HTTP message with SSL around it.
If you need to debug your traffic I suggest the following:
Use a network traffic watcher (like Ethereal) to watch the creation of connections. This will let you see the connection be initiated. It will show you the start of the SSL Handshake, details on failures, and when the session is set up, there will be chains of cipher text. The ciphertext is not very useful, but its presence lets you know data is going back and forth.
Deubg your http layer in the clear prior to setting up HTTPS. Every application or web server I've ever worked with has let me turn off HTTPS, and host the same set of URLs in the clear. Do this, and watch it with the same network tool.
If you get both sides talking with HTTP and everything breaks on HTTPS, it's time to look at either the SSL session establishment or anything in between the two points that may be interrupting the flow.
YES https flow is encrypted. When an https connection is initialized, it uses a strong encryption algorithm to handshake and agree with other part on a less strong, but much faster encryption algorithm for the flow.
To observe network packets, you can use sniffers like http://www.ethereal.com/.
When using HTTPS, the entire content of the request and reply are encrypted, including the headers and body. The HTTP protocol in plaintext happens on top of, TLS or SSL, so what's on the wire is encrypted.
The entire HTTP session is encrypted including both the header and the body.
Any packet sniffer should be able to show you the raw traffic, but it'll just look like random bytes to someone without a deep understanding of SSL, and even then you won't get beyond seeing the key exchange as a third party.
Any packet capture/sniffing tool can show you the raw HTTPS traffic. To view the actual contents (by decrypting it), use Fiddler.
Anything sent over https is encrypted using SSL transport
Try WireShark or Fiddler as helpful tools for this.