I have noticed a lot of very large websites make you log in using HTTPS and then immediately switch back over to HTTP once I am logged in (myfitnesspal.com, pluralsight.com). If I use a packet sniffer I can see the session id cookie and verify that the request is being sent via HTTP. Doesn't this mean that someone could easily hijack my session if they were listening, or is there something else I am missing? Also, on a similar note is there any reason that I would want to use HTTP over HTTPS other than the additional computation on the server?
It depends how sessions are being handled. It is possible that two sessions are being handled by the server. One secured and one unsecured.
When you log into these sites they may set two session cookies, one for browsing and one for secure access to admin/account management/checkout areas. The second cookie would be marked as "SECURE" and only be sent over a TLS/SSL connection. When browsing normally, etc only the unsecured connection is used and only to maintain state in the session, but when you go to account management, checkout, etc, then you are switched back to the secure session for those purposes. If it has been too long since your last secure access you may be asked to reauthenticate.
So while it is possible that your browsing session could be hijacked, it is unlikely (if properly implemented) that your account could be compromised as a result.
Well you can see the Session cookie if its not secure flagged or for example if you see go to wireshark and search for HTTP on your LAN, and you look at the traffic for your example: pluralsight, you just press Follow TCP STREAM on your HTTP connection to the site were after log in you see its on http data stream, and just collect the sessionid and grab greasemonkey(firefox tool) + session hijack : and ctrl+v your collected sessionid and you will see for yourself it there is a vulnerability or not.
Related
Once a webpage is served over HTTPS, we can be fairly certain that they are who we intended.
At this point, the only security risk left is that the website itself is malicious or has a security vulnerability.
For example, you may enter your credit card details which are sent to their server, and their server could release those details to the public.
I'm now trying to figure out the reasons why browsers do not allow non-SSL connections when the webpage was already served over HTTPS?
For example, browsers will stop allowing non-SSL HTTP and WS content, and don't expose UDP or TCP socket APIs.
To me there is the exact same risk that they don't use SSL on their server anyway. If anything, HTTPS could now be giving a false sense of security.
I could only identify two reasons:
To prevent webpages from accidentally using non-SSL connections. So I can understand that a form or image should only allow HTTPS. But I believe that browsers should allow, for example, UDP sockets but must be created like so (confirming that the programmer is aware of security risks):
udp = new SomeBrowserAPI.CreateUDPSocket()
udp.amAwareThat("Nothing is encrypted over UDP and I should not send any sensitive data here")
udp.amAwareThat("I cannot confirm the identity of who I am sending data to or receiving data from")
A client-side developer should not have to worry about security risks, but rather UI etc. By being forced to communicate to the server over SSL, it is up to the backend developers to worry about security only. However, this is already not the case anyway. If you are a client-side developer, you could easily write malicious client-side code that reads password input and sends it to your own server, as long as your own server is also over SSL (although SSL might at least allow you to identify who was responsible).
Are there any other reasons? Are my reasons / solutions / info correct?
There is a basic post in Google's Web Fundamentals: What is mixed content?
It is very basic, but lists three major threats: data authentication, data integrity and data confidentiality.
When you connect over UDP, you don't know
who actually serves your connection. It might have been intercepted by enemies;
whether the data received is actually the data sent. It might have been tampered by a man-in-the-middle;
who else have read your messages. Big brother is watching you.
Mixed content ruins the concept of secure webpages.
If I am running a HTTPS only service, is there any reason not to enable HSTS? Is there a strategy to test HSTS without permanently enabling it or a way "out of" HSTS?
I'd like to add to Mike's answer the warning, that you are probably not running an HTTPS-only service. The reason is that when your server doesn't listen on port 80 then if you only type in the domain and not the protocol (stackoverflow.com instead of https://stackoverflow.com) your browser will not automatically try to connect on port 443 (https) and show a connection error. Thus for most sites an HTTPS only service is out of the question.
The classical way to ensure an https connection by forwarding every http page to an https page via 301/303 forwards is not a sufficient replacement for HSTS. In fact HSTS was build for that case exactly. The reason is that many bookmarks and links will still point to http and every time a user enters a URL without specifying the protocol - which is always - the browser will first try the http connection. An active attacker can hijack that first connection and never forward the user to the https site.
To give you a more vivid image of such an attack imagine a state who spoofs every DNS request to twitter and answers with its own IPs. When it receives an https request it forwards it to twitter without any action (and chance for interception). But when it receives an http request it uses the tool ssl strip Mike has mentioned to transparently forward the content of the connection to twitter's TLS port. Neither the user nor twitter notice that anything is off (except for the very alert users who checks for TLS encryption) but the state has access to every login password.
HSTS can protect those users that have had a legitimate https connection with the server before and have already seen an HSTS header. The header instructs the browser to exchange every http url of the domain with an https url itself (before an http connection is established at all) and deny any unencrypted connection to this domain. Thus in the scenario above almost all users will not end up on the compromised http connection and are safe against the nation wide attack.
From a defense in depth perspective, you should still enable HTTP Strict Transport Policy (HSTS). There are some issues that could crop up in the future that would benefit from HSTS, including:
Server misconfiguration, where HTTP is accidentally turned on. There's one site I visited recently that takes credit card details, it has a HTTPS site but Google links to their HTTP site so depending on how you got there, you could be submitting your details in the clear.
Malicious attacker poisons or hijacks DNS records to redirect the client to their own HTTP-only server, perhaps in conjunction with an ssl strip attack.
You should also ensure a sufficiently long HSTS lifetime, e.g. a year or more.
You can disable support for HSTS by setting the max-age to 0. You'll need to leave this header in place for as long as you had originally set the value. E.g. If you had set it to 2 years, and change your mind, you'll need to leave max-age=0 for at least 2 years (and continue to offer an HTTPS service on that domain) so past clients won't have any issues connecting to it.
I'd like to open a browser in Windows, go to an HTTPS site, and perform a sequence of actions while capturing packets with Wireshark. Then I want to use the encrypted packet capture to view the decrypted HTTP traffic. I know of many ways to do this (listed below) if you forego the browser, have access to the server, or add a MITM, but none of these work when you're restricted to the scenario above. Here are my typical approaches:
Server: For sites where I have the server private key, use Wireshark's built-in SSL decryption.
MITM: An SSL proxy (e.g., Burp suite) will allow viewing of decrypted traffic, but this requires using a different certificate and key pair than what is used by the server.
Browser: openssl's s_client can connect, make requests, and export the master secret, but this does not display the associated web pages or run javascript to compute subsequent request parameters.
Is there a way to export the master secret from a "normal" browser so that I can use it to later decrypt a packet capture of the browser session?
For example, is SSL/TLS state stored on disk when a browser is closed? If so, how would I access it? Is it accessible in memory while the browser is running (and if so how would I find it)?
Or, is all SSL state data stored by the OS (Windows) and not accessible directly?
Alternatively, is there a way to force a browser to use a particular master secret (and any other associated SSL state data like session ID, etc.) for a particular HTTPS connection? If so, I could set up the SSL session using s_client, and then transfer the key data to the browser and open a new connection in the same session. This would accomplish the same goal through different means.
For browsers that use the NSS library (e.g. Firefox) you can set the SSLKEYLOGFILE environment variable, which will cause NSS to save the necessary secrets. You can then directly use that file with Wireshark. There's more information to be found here.
Are attacks like MITM possible when using HTTPS?
I know they are possible if the connection starts with HTTP then gets redirected to HTTPS, but what if the initial connection itself is using HTTPS?
I'm implementing a client which connects to a server using HTTPS and want to find out if my explicitly determining the authenticity of the server is necessary (not, not the server authenticating the client is who it says it is, but the client ensuring the server is who it says it is) - I'm doing this in iOS where an API is available which makes it easy to do, but I'm not sure if its necessary to do, and if I do, then how to test that it works.
Thanks
It's absolutely possible to MITM SSL, and it's often pretty easy if you don't actually check the server's certificate.
Consider someone using your app in a coffee shop where a malicious employee has control over the wireless router. They can watch for HTTPS connections to your server and redirect them to a local MITM program. That program accepts the connection using a self-signed SSL certificate, say, and then opens a connection to your real server and proxies traffic between them.
As long as you check the validity of the server's certificate, this simple attack is thwarted. So do that. :-)
There are much more complicated attacks that have been demonstrated that can still, under special circumstances, MITM an SSL connection even when you check the certificates, but the circumstances that make those attacks work are difficult enough to arrange that most developers needn't worry about them.
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.