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.
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.
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.
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)?
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.
This question already has answers here:
Is a HTTPS query string secure?
(9 answers)
Closed 9 years ago.
Suppose I setup a simple php web server with a page that can be accessed by HTTPS. The URL has simple parameters, like https://www.example.com/test?abc=123.
Is it true that the parameter here in this case will be safe from people sniffing the packets? And would this be true if the server does not employ any SSL certificate?
Yes your URL would be safe from sniffing; however, one hole that is easily overlooken is if your page references any third party resources such as Google Analytics, Add Content anything, your entire URL will be sent to the third party in the referer. If its really sensitive it doesn't belong in the query string.
As for your second part of the question, you can't use SSL if you don't have a certificate on the server.
http://answers.google.com/answers/threadview/id/758002.html
HTTPS Establishes an underlying SSL
connection before any HTTP data is
transferred. This ensures that all URL
data (with the exception of hostname,
which is used to establish the
connection) is carried solely within
this encrypted connection, and is
protected from man-in-the-middle
attacks in the same way that any HTTPS
data is.
All HTTP-level transactions within an
HTTPS connection are conducted within
the established SSL session, and no
query data is transferred before the
secure connection is established.
From the outside the only data that is
visible to the world is the hostname
and port you are connecting to.
Everything else is simply a stream of
binary data which is encrypted using a
private key shared only between you
and the server.
In the example you provide your
browser would do this:
Derive
hostname (and port if present)
from URL.
Connect to host.
Check certificate (it must be 'signed'
by a known authority, applied specifically
to correct IP address and port, and be
current).
The browser and server
exchange cryptographic data and the
browser receives a private key.
The
HTTP request is made, and encrypted with
established cryptography.
HTTP response is received. Also encrypted.
HTTP is an 'Application Layer'
protocol. It is carried on top of the
secure layer. According to the SSL
specification, drawn up by Netscape,
it dictates that no application layer
data may be transmitted until a secure
connection is established - as
outlined in the following paragraph:
"At this point, a change cipher spec
message is sent by the client, and the
client copies the pending Cipher Spec
into the current Cipher Spec. The
client then immediately sends the
finished message under the new
algorithms, keys, and secrets. In
response, the server will send its own
change cipher spec message, transfer
the pending to the current Cipher
Spec, and send its finished message
under the new Cipher Spec. At this
point, the handshake is complete and
the client and server may begin to
exchange application layer data."
http://wp.netscape.com/eng/ssl3/draft302.txt
So yes. The data contained in the URL
query on an HTTPS connection is
encrypted. However it is very poor
practice to include such sensitive
data as a password in a 'GET'
request. While it cannot be
intercepted, the data would be logged
in plaintext server logs on the
receiving HTTPS server, and quite
possibly also in browser history. It
is probably also available to browser
plugins and possibly even other
applications on the client computer.
At most a HTTPS URL could be
reasonably allowed to include a
session ID or similar non-reusable
variable. It should NEVER contain
static authentication tokens.
The HTTP connection concept is most
clearly explained here:
http://www.ourshop.com/resources/ssl_step1.html
The requested URI (/test?abc=123) is sent to the web server as part of the HTTP request header and thus encrypted.
However URLs can leak in other ways, usually web browser toolbars, bookmarks, and sending links to friends. POSTing data may be more appropriate depending on the context/sensitivity of the data you're sending.
I believe an HTTPS connection requires an SSL certificate, even a self-generated one if you don't want to buy one.
Hope that helps a bit!
depends on what you mean by safe
SSL encrypts the entire HTTP request/response, so the URL in the GET portion will be encrypted. This does not stop MITM attacks and corruption of the integrity of the SSL session itself. If a non-authoritative certificate is used, this makes potential attack vectors simpler.
Are REST request headers encrypted by SSL?
Is a similar question.
The url:s will be stored both in the server logs and in the browser history so even if they aren't sniffable they are far from safe.
On the wire, yes. At the end points (browser and server) not necessarily. SSL/TLS is transport layer security. It will encrypt your traffic between the browser and the server. It is possible on the browser-side to peek at the data (a BHO for example). Once it reaches the server-side, it is available to the recipient of course and is only as secure as he treats it. If the data needs to move securely beyond the initial exchange and protected from prying eyes on the client, you should also look at message layer security.
The SSL/TSL is a Transport Layer Security, yes the data can be picked with BHO (as #JP wrote) or any add on but also with "out of browser" HTTP sniffers. They read messaging between winsock32 and the application. The encryption takes place in the winsock32 not in the browser.
Take a look (this part was taked from the page of IEinspector):
IEInspector HTTP Analyzer is such a handy tool that allows you to monitor, trace, debug and analyze HTTP/HTTPS traffic in real-time.