Say I was trying to access https://www.secretplace.com/really/really/secret.php, what's actually sent in plain text before the SSL session is established?
Does the browser intervene, see that I want https, initiate a SSL session with secretplace.com (i.e. without passing the path in plain text) and only after the SSL session is set up pass the path?
Just curious.
HTTP Secure
The level of protection depends on the correctness of the implementation of the web browser and the server software and the actual cryptographic algorithms supported.
Also, HTTPS is vulnerable when applied to publicly-available static content. The entire site can be indexed using a web crawler, and the URI of the encrypted resource can be inferred by knowing only the intercepted request/response size. This allows an attacker to have access to the plaintext (the publicly-available static content), and the encrypted text (the encrypted version of the static content), permitting a cryptographic attack.
Because SSL operates below HTTP and has no knowledge of higher-level protocols, SSL servers can only strictly present one certificate for a particular IP/port combination. This means that, in most cases, it is not feasible to use name-based virtual hosting with HTTPS. A solution called Server Name Indication (SNI) exists which sends the hostname to the server before encrypting the connection, although many older browsers don't support this extension. Support for SNI is available since Firefox 2, Opera 8, and Internet Explorer 7 on Windows Vista.
In general, the name of the server you are talking to is leaked ("stackoverflow.com"). This was probably leaked via DNS before SSL/TLS could begin connecting, though.
The server's certificate is leaked. Any client certificate you sent (not a common configuration) may or may not have been sent in-the-clear. An active attacker (man-in-the-middle) could probably just ask your browser for it and receive it anyway.
The path portion of the URL ("/questions/2146863/how-much-data-is-leaked-from-ssl-connection") should NOT be leaked. It is passed encrypted and secure (assuming the client and server are set up correctly and you didn't click-through any certificate errors).
The other poster is correct, that there are possible traffic analysis attacks which may be able to deduce some things about static content. If the site is very large and dynamic (say stackoverflow.com) I suspect that it could be quite difficult to get much useful info out of it. However, if there are only a few files with distinctive sizes, which downloads could be obvious.
Form POST data should NOT be leaked. Although usual caveats apply if you are transmitting objects of known sizes.
Timing attacks may reveal some information. For example, an attacker ccould put stress on various parts of the application (e.g., a certain database table) or pre-load some static files from the disk and watch how your connection slows down or speeds up in response.
This is an information "leak" but probably not a big deal for most sites.
The request is made by your browser to https://url:443, and that's in the clear. Then the server and client will negotiate a ciphersuite to protect the data. Normally, this will include a symmetric encryption algorithm (eg; 3DES or RC4 or AES) and a message authentication code (such as HMAC-SHA1) to detect tampering. Note that technically, both of these are optional, it IS possible to have SSL with no encryption but unlikely today.
Once the client (your browser) and the web server have agreed on a ciphersuite and keys are determined, the rest of the conversation is protected.
To be honest, I would hook up a protocol analyzer and watch it all unfold before your eyes!!
Remember, that SSL is at the Transport layer of the TCP/IP stack, it's below the browser data, so it's all protected.
Hope that helps.
Related
I'd like to know if it's possible for web services to detect HTTPS connections with "faked" root certificates created by Fiddler4 (Web debugging proxy) to prevent reverse engineering.
Is there any method to check whether the encryption is done with the original certificate or with one made by Fiddler?
A server has no way to know what certificate the client received unless the client sends the server that information.
From client JavaScript, you cannot detect such interception today; JavaScript does not expose the capabilities to introspect the certificate. It is possible to use Java or Flash inside a webpage to inspect the certificate received upon connecting to a server, but a sufficiently devious interceptor could just avoid MITM'ing the Java/Flash connection.
In contrast, a native code client application can detect what certificate was presented by the server and reject any certificate that doesn't match the expected certificate; this is called certificate pinning and it's a technique used by some applications. Note that this will block more than Fiddler; it'll also block connections through corporate inspection proxies (e.g. BlueCoat, ISA TMG, etc) and through some popular consumer antivirus programs' proxies (e.g. BitDefender). More importantly, users can circumvent your certificate pinning checks if they like; your code is running on their device, and they have the ability to modify your code in memory to strip out your certificate pinning checks. On some mobile devices, this code modification requires "jail-breaking" the device, but this isn't an insurmountable barrier.
I'm trying to determine how much of a security risk I'm looking at
when I have rubycas itself running over https, but my actual sites
running under http. the reason I'm faced with this issue is that the
sites are deployed on heroku, which means ssl is either really
expensive or really a pain.
In addition to the login details, i also pass user rolls
(authorization) to each site that is then stored in a session.
Any input is greatly appreciated.
The problem with this approach is that neither the sessionid (url or cookie) nor the exchanged data is encrypted. Therefore the data can be read and manipulated both on the way from the server to the user and on the way from the user to the server.
Even a passive attacker that can just sniff the traffic without being able to manipulate it, can create damage: The attacker can just copy the sessionid into his or her own browser. Public wireless connections often use a transparent proxy, so both the attacker and the victim have the same public ip-address, which makes it difficult for the application to tell them apart.
There is a tool called Firesheep that makes this kind of attack extremely easy.
This question tries to look into whether doing HTTPS log in is very important for any website.
Is it true that for many websites, if the login is done through HTTP but not HTTPS, then anybody can pretty much see the userID and password easily along the internet highway (or by looking between a router and the internet connection in an Internet Cafe)?
If so... do popular frameworks actually use HTTPS by default (or at least as an option), such as Rails 2.3.5 or Django, CakePHP, or .Net?
Yes, any machine on the pathway (that the packets pass through) can just examine the contents of the those packets. All it takes is a capturing proxy or a promiscuous mode network card with something like WireShark. Assuming that the passwords aren't encrypted in some other way (at a higher level), they will be visible.
I can't answer the second part of your question since I have no knowledge of those particular products but I would say that the inability to use secure sockets would pretty much make them useless.
Pax is right about passwords that aren't otherwise encrypted being visible.
Still, most sites don't use SSL still, and it does put the users at a certain degree of risk when accessing sites from public wifi.
HTTPS isn't a framework level option, it would be something you'd do when you set up the webserver. If you were to use an apache configuration for instance, you would open it up to a properly configured https, close http and install a certification. The framework wouldn't have a direct influence on that portion of the release.
If the user credentials are submitted via an HTML webform without HTTPS, then it is unsecure, the data is submitted in plain text. However, if the website uses HTTP authentication instead, then the server can send back a 401 reply (or 407 for proxies) to any request that does not provide valid credentials. 401/407 is the server's way to ask for credentials, and the reply provides a list of authentication schemes (Digest, NTLM, Negotiate, etc) that the server supports, which are usually more secure by themselves. The client/browser sends the same request again with the necessariy credentials in one of the schemes, then the server either sends the requested data, or sends another 401/407 reply if the credentials are rejected.
I am writing a little app similar to omegle. I have a http server written in Java and a client which is a html document. The main way of communication is by http requests (long polling).
I've implemented some sort of security by using the https protocol and I have a securityid for every client that connects to the server. When the client connects, the server gives it a securityid which the client must always send back when it wants a request.
I am afraid of the man in the middle attack here, do you have any suggestions how I could protect the app from such an attack.
Note that this app is build for theoretical purposes, it won't be ever used for practical reasons so your solutions don't have to be necessarily practical.
HTTPS does not only do encryption, but also authentication of the server. When a client connects, the server shows it has a valid and trustable certificate for its domain. This certificate can not simply be spoofed or replayed by a man-in-the-middle.
Simply enabling HTTPS is not good enough because the web brings too many complications.
For one thing, make sure you set the secure flag on the cookies, or else they can be stolen.
It's also a good idea to ensure users only access the site via typing https://<yourdomain> in the address bar, this is the only way to ensure an HTTPS session is made with a valid certificate. When you type https://<yourdomain>, the browser will refuse to let you on the site unless the server provides a valid certificate for <yourdomain>.
If you just type <yourdomain> without https:// in front, the browser wont care what happens. This has two implications I can think of off the top of my head:
The attacker redirects to some unicode domain with a similar name (ie: looks the same but has a different binary string and is thus a different domain) and then the attacker provides a valid certificate for that domain (since he owns it), the user probably wouldn't notice this...
The attacker could emulate the server but without HTTPS, he would make his own secured connection to the real server and become a cleartext proxy between you and the server, he can now capture all your traffic and do anything he wants because he owns your session.
We currently have a group of web-services exposing interfaces to a variety of different client types and roles.
Background:
Authentication is handled through SSL Client Certificate Verification. This is currently being done in web-service code (not by the HTTP server). We don't want to use any scheme less secure than this. This post is not talking about Authorisation, only Authentication.
The web-services talk both SOAP and REST(JSON) and I'm definitely not interested in starting a discussion about the merits of either approach.
All operations exposed via the web-services are stateless.
My problem is that verifying the client certificate on each requests is very heavyweight, and easily dominates CPU time on the application server. I've already tried seperating the Authentication & Application portions onto different physical servers to reduce load, but that doesn't improve dispatch speed overall - the request still takes a constant time to authenticate, no matter where that is done.
I'd like to try limiting the number of authentications by generating an HTTP cookie (with an associated server-side session) after successful client certificate verification, which when supplied by the client will cause client certificate verification to be skipped (though still talking over SSL). I'd also like to time-limit the sessions, and make the processes as transparent as possible from a client perspective.
My questions:
Is this still as secure? (and how can we optimise for security and pragmatism?)
Are there free implementations of this scheme? (I'm aware of the SiteMinder product by CA)
Given the above, should we continue to do Authentication in-application, or move to in-server ?
generating an HTTP cookie (with an
associated server-side session) after
successful client certificate
verification, which when supplied by
the client will cause client
certificate verification to be skipped
Is this still as secure? (and how can
we optimise for security and
pragmatism?)
It's not quite as secure in theory, because the server can no longer prove to himself that there's not a man-in-the-middle.
When the client was presents a client-side certificate, the server can trust it cryptographically. The client and server should be encrypting and data (well, the session key) based on the client's key. Without a client-side cert, the server can only hope that the client has done a good job of validating the server's certificate (as perceived by the client) and by doing so eliminated the possibility of Mr. MitM.
An out-of-the-box Windows client trusts over 200 root CA certificates. In the absence of a client-side cert, the server ends up trusting by extension.
Here's a nice writeup of what to look for in a packet capture to verify that a client cert is providing defense against MitM:
http://www.carbonwind.net/ISA/ACaseofMITM/ACaseofMITMpart3.htm
Explanation of this type of MitM.
http://www.networkworld.com/community/node/31124
This technique is actually used by some firewall appliances boxes to perform deep inspection into the SSL.
MitM used to seem like a big Mission Impossible-style production that took a lot to pull off. Really though it doesn't take any more than a compromised DNS resolver or router anywhere along the way. There are a lot of little Linksys and Netgear boxes out there in the world and probably two or three of them don't have the latest security updates.
In practice, this seems to be good enough for major financial institutions' sites, although recent evidence suggests that their risk assessment strategies are somewhat less than ideal.
Are there free implementations of this scheme? (I'm aware of the SiteMinder product by CA)
Just a client-side cookie, right? That seems to be a pretty standard part of every web app framework.
Given the above, should we continue to do Authentication in-application, or move to in-server ?
Hardware crypto accelerators (either a SSL proxy front end or an accelerator card) can speed this stuff up dramatically.
Moving the cert validation into the HTTP server might help. You may be doing some duplication in the crypto math anyway.
See if you would benefit from a cheaper algorithm or smaller key size on the client certs.
Once you validate a client cert, you could try caching a hash digest of it (or even the whole thing) for short time. That might save you from having to repeat the signature validations all the way up the chain of trust on every hit.
How often to your clients transact? If the ones making up the bulk of your transactions are hitting you frequently, you may be able to convince them to combine multiple transactions in a single SSL negotiation/authentication. Look into setting the HTTP Keep-Alive header. They may be doing that already to some extent. Perhaps your app is doing client cert validation on every HTTP request/response, or just once at the beginning of each session?
Anyway, those are some ideas, best of luck!