I have a question: What is the difference between sniffing and forwarding.
I mean that when I am in the MITM position (the gateway of a client), I can access to all the HTTPS website with this client browser.
In addition, I can check the generated traffic on the gateway side (including HTTPS requests/answers - encrypted of course!).
But as soon as I am using tools called "sniffers" (ettercap for instance) on the gateway side I am getting certificate errors and cannot even acces those HTTPS websites on the client side.
I am thus wondering what is the difference between sniffing and forwarding the traffic, in both cases we have access to the exact same information on the gateway side (generated traffic).
Finally, when sending HTTPS requests, those request has to go throw numerous routers to reach the server destination, a router is not a sniffer I suppose that is why we don't get the SSL certificate errors, right?
Sniffing is passive, whereas forwarding (MITM) is active.
When forwarding (MITM), you are part of the route. The traffic goes from the client to your IP address, then on to the server.
When sniffing, you're simply on the same physical network as the client and are able to receive a copy of the packets that the client is sending to the server.
If sniffing is causing HTTPS to fail, then there's something wrong. Perhaps you have mixed up the two terms?
Related
Is http ok vs https in an intranet connected to the internet ?
If a bank has a website which using http and only accessible if connected to the network, is this a security risk?
Not sure if I understood your question, but let me try an answer.
HTTPS has the objective to guarantee that no one in the middle of the connection is being able to see what you and the server are talking to each other, he does it using encryption, so even in an intranet using HTTPS has its advantages.
Imagine a wireless connection, everyone in the bank is in the middle of you and the connection with the router (consequently, the server) if you are using it, so if this website has sensitive information like a password, even in an intranet, you would want it secure so no one inside that network can sniff packets and get your password easily in a clear HTTP request.
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 too feel that this is a stupid question but I'm unsure if capturing traffic will work if the host is offline? I was actually discussing about Man-in-The-Middle attacks and just thought lets suppose https://example.com is offline (down or blocked on a network) and someone made a request to http://example.com/example-category/example so will an attacker be able to capture this complete GET request in a local network?
I think yes because the request will anyhow be sent from the client to host and there it should be captured. If that is the case then can HTTPS traffic be also captured (talking only GET based) if the host is offline or blocked intentionally on a local network?
If the man in the middle is located in the network before the host is found unreachable (for example in the local network before the router), then yes, the request would go to the MITM.
Yet the MITM might be in a bit of a situation if he finds destination host unreachable from his network, too.
If the router/gateway that is blocking the request is before the MITM, the request will be blocked and not received by the MITM.
If there is no MITM, but just traffic monitoring, there will be no connection made and thus no request transmitted to be monitored.
As to HTTPS: If the MITM cannot provide a valid certificate for the domain name (usually, MITM cannot), the connection would fail on the TLS part.
No. Before the http request itself can be sent, the initial TCP connection has to be established. And if the host is offline, then the TCP connection CANNOT be established.
No connection, no request, therefore nothing to sniff. The only thing that COULD be sniffed/intercepted would therefore be the initial TCP SYN packet, and that by itself is essentially useless.
It's like dialing a phone number that doesn't exist - the attempt to dial can be monitored, but since the call can never be established, there's no voice chatter to intercept.
In my setup, I have 2 layers of transparent proxies. When a client makes an SSL request, I wish to have the first proxy it meets simply forward the traffic to another one without attempting to do the handshake with the client.
The setup seems funny, but it is justified in my case - the 2nd proxy registers itself to the first one (through some other service) only occassionally. It tells the first: "I'm interested in some traffic that looks like___". In most cases, the 1st proxy simply does the work.
Can an httpProxy (in node-proxy) proxy SSL requests? Must I use an httpsProxy (which will then do the handshake with the client)?
You could do all of this with the existing httpsProxy if you wanted to. Unless you are wanting to use a non-Node proxy or proxy to a different server, I can't see what you would gain by having two.
Simply add the required the logging/signing logic to the existing httpsProxy.
Typically, I use https on the proxy to both restrict the number of open ports and to remove the need to do https on all of the Node servers running. You can also add Basic Auth using http-basic library too.
See my example code: https://github.com/TotallyInformation/node-proxy-https-example/blob/master/proxy.js
EDIT 2012-05-15: Hmm, after some thought, I wonder if you shouldn't be looking at something like stunnel to do what you want rather than Node?
(For reference, I've already made some of those points in my answer to your similar question on ServerFault.)
If you are after a MITM proxy (that is, a proxy that can look inside the SSL content by using its own certificates, which can work provided the clients are configured to trust them), it will hardly be fully transparent, since you will at least have to configure its clients to trust its certificates.
In addition, unless all your client use the server name indication extension, the proxy itself will be unable to determine reliably which host to issue its certificate for (something that a normal HTTPS proxy would have been able to know by looking at the CONNECT request issued by the client).
If you're not after a MITM proxy, then you might as well let the initial connection through via your router. If you want to record that traffic, your router might be able to log the encrypted packets.
Having your router catch the SSL/TLS packets to send them transparently to a proxy that will merely end up relaying that traffic untouched anyway to the target server doesn't make much sense. (By nature, the transparent proxy will imply the client isn't configured to know about it, so it won't even send its CONNECT method with which you could have had the requested host and port. Here, you'll really have nothing more than what the router can do.)
EDIT: Once again, you simply won't be able to use an HTTP proxy to analyse the content of the connection transparently. Even when using a normal proxy, an HTTPS connection is relayed straight through to the target server. The SSL/TLS connection itself is established between the original client and the target server. The point of using SSL/TLS is to protect this connection, and to make the client notice if something is trying to look inside the connection.
Plain HTTP transparent proxy servers work because (a) the traffic can be seen (in particular, the request line and the HTTP Host header are visible so that the proxy can know which request to make itself) and (b) the traffic can be altered transparently so that the initial client doesn't notice that the request wasn't direct and works as if it was.
Neither of these conditions are true with HTTPS. HTTPS connections that go through an HTTP proxy are simply tunnel, after explicit request from the client, which has sent a CONNECT command and was configured to make use of such a proxy.
To do something close to what you're after, you'd need an SSL/TLS server that accepts the SSL/TLS connection and deciphers it (perhaps something like STunnel) before your HTTP proxy. However, this won't be transparent, because it won't be able to generate the right certificates.
When sending data over HTTPS, I know the content is encrypted, however I hear mixed answers about whether the headers are encrypted, or how much of the header is encrypted.
How much of HTTPS headers are encrypted?
Including GET/POST request URLs, Cookies, etc.
All the HTTP headers are encrypted†.
That's why SSL on vhosts doesn't work too well - you need a dedicated IP address because the Host header is encrypted.
†The Server Name Identification (SNI) standard means that the hostname may not be encrypted if you're using TLS. Also, whether you're using SNI or not, the TCP and IP headers are never encrypted. (If they were, your packets would not be routable.)
The headers are entirely encrypted. The only information going over the network 'in the clear' is related to the SSL setup and D/H key exchange. This exchange is carefully designed not to yield any useful information to eavesdroppers, and once it has taken place, all data is encrypted.
New answer to old question, sorry. I thought I'd add my $.02
The OP asked if the headers were encrypted.
They are: in transit.
They are NOT: when not in transit.
So, your browser's URL (and title, in some cases) can display the querystring (which usually contain the most sensitive details) and some details in the header; the browser knows some header information (content type, unicode, etc); and browser history, password management, favorites/bookmarks, and cached pages will all contain the querystring. Server logs on the remote end can also contain querystring as well as some content details.
Also, the URL isn't always secure: the domain, protocol, and port are visible - otherwise routers don't know where to send your requests.
Also, if you've got an HTTP proxy, the proxy server knows the address, usually they don't know the full querystring.
So if the data is moving, it's generally protected. If it's not in transit, it's not encrypted.
Not to nit pick, but data at the end is also decrypted, and can be parsed, read, saved, forwarded, or discarded at will. And, malware at either end can take snapshots of data entering (or exiting) the SSL protocol - such as (bad) Javascript inside a page inside HTTPS which can surreptitiously make http (or https) calls to logging websites (since access to local harddrive is often restricted and not useful).
Also, cookies are not encrypted under the HTTPS protocol, either. Developers wanting to store sensitive data in cookies (or anywhere else for that matter) need to use their own encryption mechanism.
As to cache, most modern browsers won't cache HTTPS pages, but that fact is not defined by the HTTPS protocol, it is entirely dependent on the developer of a browser to be sure not to cache pages received through HTTPS.
So if you're worried about packet sniffing, you're probably okay. But if you're worried about malware or someone poking through your history, bookmarks, cookies, or cache, you are not out of the water yet.
HTTP version 1.1 added a special HTTP method, CONNECT - intended to create the SSL tunnel, including the necessary protocol handshake and cryptographic setup.
The regular requests thereafter all get sent wrapped in the SSL tunnel, headers and body inclusive.
HTTPS (HTTP over SSL) sends all HTTP content over a SSL tunel, so HTTP content and headers are encrypted as well.
With SSL the encryption is at the transport level, so it takes place before a request is sent.
So everything in the request is encrypted.
Yes, headers are encrypted. It's written here.
Everything in the HTTPS message is encrypted, including the headers, and the request/response load.
the URL is also encrypted, you really only have the IP, Port and if SNI, the host name that are unencrypted.
To understand, what is encrypted and what not, you need to know that SSL/TLS is the layer between the transport-layer and the application-layer.
in the case of HTTPS, HTTP is the application-layer, and TCP the transport-layer. That means, all Headers below the SSL-Level are unencrypted. Also, SSL itself may expose data. The exposed data includes(for each layer's Header):
NOTE: Additional Data might be exposed too, but this data is pretty sure to be exposed.
MAC:
Source MAC address(Current Hop)
Destination MAC address(Next Hop)
IP(assuming IPv4):
Destination IP address
Source IP address
IP Options(if set)
Type-Of-Service(TOS)
The number of hops the current packet passed, if TTL is set to 64
TCP:
Source Port
Destination Port
TCP-Options
Theoretically, you can encrypt the TCP-Headers, but that is hard to implement.
SSL:
Hostname(if SNI is being used)
Usually, a browser won't just connect to the destination host by IP immediantely using HTTPS, there are some earlier requests, that might expose the following information(if your client is not a browser, it might behave differently, but the DNS request is pretty common):
DNS:
This request is being sent to get the correct IP address of a server. It will include the hostname, and its result will include all IP addresses belonging to the server.
HTTP:
the first request to your server. A browser will only use SSL/TLS if instructed to, unencrypted HTTP is used first. Usually, this will result in a redirect to the seucre site. However, some headers might be included here already:
User-Agent(Specification of the client)
Host (Hostname)
Accept-Language (User-Language)