Can we implement Web session management relying on HTTPS protocol - security

Webserver provide explicit session management as HTTP protocol is stateless.
Suppose if I am writing a new web server and I know that I will support only HTTPS can I rely on HTTPS for session management?

Probably not.
Requiring a stable SSL/TLS session identifier (SSL_SESSION_ID) as essential for functionality is likely to break the site for too many real users. SSL clients aren't mandated to keep it the same over an extended period of time, and some browsers may not. I believe IE<8 can drop the connection and negotiate a new session arbitrarily.
There are also operational concerns... for example it'll break if you host it behind a terminating reverse proxy, and you'd have to be careful with caching as there is no Vary:-on-SSL-session-ID possible.
It certainly has interesting potential for tracking and risk rating as part of a wider system, but from what I've seen of people who've tried it (which does not include me, so take this with a pinch of salt) it's probably not a reliable replacement for cookies today.

The answer: You can not manage your application state relying on HTTPS protocol.
Both HTTP and HTTPS are stateless.
You should manage your application state using your Web Server session management.

Related

Why do browsers forbid non-SSL connections when a webpage was already served over HTTPS?

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.

Is it a good practice to use Socket.IO's emit() instead of all HTTP requests?

I set up a Node.js HTTP server. It listens to path '/' and returns an empty HTML template on a get request.
This template includes Require.js client script, which creates Socket.IO connection with a server.
Then all communication between client and server is provided by Web Sockets.
On connection, server requires authentication; if there are authentication cookies then client sends them to server for validation, if no cookies then client renders login view and waits for user input, etc.
So far everything works, after validating credentials I create a SID for user and use it to manage his access rights. Then I render main view and application starts.
Questions:
Is there a need to use HTTPS instead of HTTP since I'm only using HTTP for sending script to the client? (Note: I'm planning to use Local Storage instead of cookies)
Are the any downfalls in using pure Web Sockets without HTTP?
If it works, why nobody's using that?
Is there a need to use HTTPS instead of HTTP since I'm only using HTTP
for sending script to the client? (Note: I'm planning to use Local
Storage instead of cookies)
No, HTTP/HTTPS is required for handshake for websockets. Choice of HTTP or HTTPS is from security point of view. If you want to use it for simply sending script then there is no harm. If you want to implement user login / authentication in your pages then HTTPS should be used.
Are the any downfalls in using pure Web Sockets without HTTP?
Web sockets and HTTP are very different. If you use pure Web Sockets you will miss out on HTTP. HTTP is the preferred choice for cross-platform web services. It is good for document traversal/retrieval, but it is one way. Web socket provides full-duplex communications channels over a single TCP connection and allows us to get rid of the workarounds and hacks like Ajax, Reverse Ajax, Comet etc. Important thing to note is that both can coexist. So aim for web sockets without leaving out HTTP.
If it works, why nobody's using that?
We live in the age of HTTP, web sockets are relatively new. In the long term, web sockets will gain popularity and take up larger share of web services. Many browsers until recently did not support web sockets properly. See here, IE 10 is the latest and only version in IE to support web sockets. nginx, a wildly popular server did not support web sockets until Feb-March 2013. It will take time for web sockets to become mainstream but it will.
Your question is pretty similar to this one
Why use AJAX when WebSockets is available?
At the end of the day they were both created for different things although you can use web sockets for most, if not everything which can be done in normal HTTP requests.
I'd recommend using HTTPS as you do seem to be sending authentication data over websockets (which will also use the SSL, no?) but then it depends on your definition of 'need'.
Downfalls - Lack of support for older browsers
It's not used this this in many other situations because it's not necessary and it's still 'relatively new'.

Applying manual AES encryption instead of using HTTPS

Due to a couple of issues with my host, I'm unable to use a SSL-certificate on my server (I'm not ready to change provider just yet), and can't therefore use HTTPS. This server will communicate with a couple of client-computers and will transfer data that's somewhat secret.
Would it be reasonable to simply use AES encryption (encryption on client before sending, decryption on server before processing) instead of HTTPS?
This depends on your deployment environment.
Replacing SSL/TLS (and HTTPS) with your own encryption protocol for use by a web browser is always a bad idea, since it relies on JavaScript code delivered insecurely (for details, see this question on Security.SE, for example).
If the client isn't a web browser, you have more options available. In particular, you can implement message-level security instead of transport-level security (which is what HTTPS uses).
There are a number of attempts to standardise message-level security with HTTP. For example:
HTTPsec had a public specification (still available on WebArchive), but a commercial implementation. I'm not sure whether this has been widely reviewed.
WS-Security, oriented towards the world of SOAP.
Perhaps more simply, if you want to re-use existing tools, you could use S/MIME or PGP (in the same way as you would for e-mails) to encrypt the HTTP message entities. Unlike HTTPS, this won't protect the URL or the HTTP headers, but this might be enough if you don't put any sensitive data there.
The further down you go with "raw encryption" yourself (using AES directly, for example), the more likely you'll have to implement other aspects of security manually (typically, verifying the remote party's identity and dealing with the problem of pre-sharing the keys).
If you have a small list of clients that don't change often, you could implement your own SSL-Tunnel using SSH. On the clients do a;
ssh -D 4444 nulluser#example.com -N
where nulluser has no shell or file access on example.com.
Then add a foxyproxy whitelist setting - so that for example.com the client browsers use the localhost:4040 proxy.
It's a hack, it's totally unscalable, but it would work as I say for a small, static number of clients, and it has the advantage of not reinventing any wheels while being totally secure.

Is session hijacking / MITMA etc. possible with HTTPS?

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.

Questions about SSL

I have a couple questions about SSL certificates.
I never used them before but my current project requires me to do so.
Question 1.
Where should you use SSL? Like I know places like logging in, resetting passwords are definite places to put it. How about once they are logged in? Should all requests go through SSL even if the data in there account is not considered sensitive data? Would that slow down SSL for the important parts? Or does it make no difference?(sort of well you got SSL might as well make everything go through it no matter what).
Question 2.
I know in smtp you can enable SSL as well. I am guessing this would be pretty good to use if your sending say a rest password to them.
If I enable this setting how can I tell if SSL if it is working? Like how do I know if it really enabled it? What happens if the mail server does not have SSL enabled and your have that boolean value enabled. Will it just send it as non SSL then?
With an SSL connection, one of the most expensive portions (relatively speaking) is the establishment of the connection. Depending on how it is set up, for example, it might create an ephemeral (created on the fly) RSA key for establishing a session key. That can be somewhat expensive if many of them have to be created constantly. If, though, the creation of new connections is less common (and they are used for longer periods of time), then the cost may not be relevant.
Once the connection has been established, the added cost of SSL is not that great although it does depend on the encryption type. For example, using 256-bit AES for encryption will take more time than using 128-bit RC4 for the encryption. I recently did some testing with communications all on the same PC where both client and server were echoing data back and forth. In other words, the communications made up almost the entire cost of the test. Using 128-bit RC4 added about 30% to the cost (measured in time), and using 256-bit AES added nearly 50% to the cost. But remember, this was on one single PC on the loopback adapter. If the data were transmitted across a LAN or WAN, then the relative costs is significantly less. So if you already have an SSL connection established, I would continue to use it.
As far as verifying that SSL is actually being used? There are probably "official" ways of verifying it, using a network sniffer is a poor man's version. I ran Wireshark and sniffed network traffic and compared a non-SSL connection and an SSL connection and looked at the raw data. I could easily see raw text data in the non-SSL version while the SSL "looked" encrypted. That, of course, means absolutely nothing. But it does show that "something" is happening to the data. In other words, if you think you are using SSL but can recognize the raw text in a network sniff, then something is not working as you expected. The converse is not true, though. Just because you can't read it, it does not mean it is encrypted.
Use SSL for any sensitive data, not just passwords, but credit card numbers, financial info, etc. There's no reason to use it for other pages.
Some environments, such as ASP.NET, allow SSL to be used for encryption of cookies. It's good to do this for any authentication or session-ID related cookies, as these can be used to spoof logins or replay sessions. You can turn these on in web.config; they're off by default.
ASP.NET also has an option that will require all authenticated pages to use SSL. Non-SSL requests get tossed. Be careful with this one, as it can cause sessions to appear hung. I'd recommend not turning on options like this, unless you really need them.
Sorry, can't help with the smtp questions.
First off, SSL is used to encrypt communications between client and server. It does this by using a public key that is used for encryption. In my opinion it is a good practice to use it for as anything that has personally identifiable information or sensitive information.
Also, it is worth pointing out that there are two types of SSL authentication:
One Way - in which there is a single, server certificate - this is the most common
Two Way - in which there is a server certificate and a client certificate - the client first verifies the server's identity and then the server ids the client's id - example is DOD CAC
With both, it is important to have up to date, signed, certificates by a reputable CA. This verifies your site's identity.
As for question 2, yes, you should use SSL over SMTP if you can. If your emails are routed through an untrusted router, they can be eavesdropped if sent without encryption. I am not sure about the 'boolean value enabled' question. I don't believe setting up SSL is simply as easy as checking a box though.
A couple people have already answered your Question 1.
For question 2 though, I wouldn't characterize SMTP over SSL as protecting the message. There could be plenty of points at which the message is exposed. If you want to protect the message itself, you need S/MIME, or something similar. I'd say SMTP over SSL is more useful for protecting your SMTP credentials, so that someone cannot grab your password.

Resources