If I open Fiddler and log into 50 different websites from my browser... in a perfect world, would Fiddler ever be able to show me my password in plain text?
If it does, is that a security problem with the website?
If not, how can you tell if a website is sending data unencrypted? Wireshark?
Did you enable HTTPS decryption in Fiddler? If so, then Fiddler is doing something that no web based attacker can easily do, and seeing your password shouldn't worry you.
If you didn't enable HTTPS decryption, or you see your password in a session whose protocol is HTTP, then the website is not sending your password securely, and anyone able to sniff your HTTP traffic could see your password.
Related
I have a trivial question about web architecture. When I build a web service/application, I want to make it only work perfectly on https protocol.
Firstly I analyzed the google's methodology by network session of chrome developer tools. In there I found it, when a http request is sended to the google, that the request redirected to https of same origin.
I thought it is a respectable way. But I find it has a potential risk. When an authorized user using the google, he have a session. And after, he want to deep another site (e.g. Yahoo). And he will come back to the google by inserting the address 'google.com' directly in browser's address box. In this situation if the user didn't shut off the google session, in the redirect process, the unencrypted session token will be sended to google because the redirect process be proceeded on http protocol. So this user will be exposed MITM(man in the middle) attack.
So I hesitate to use google methodology. Anyone have a idea?
Set the secure flag on the session cookie. Then it won't ever be sent over HTTP.
One of customers have reported that they can see the password being transferred as clear text, they probably tried tool like a fiddler to capture the HTTP request/response. So my question is is it possible using fiddler or any other tool is it possible for someone to monitor the http traffic on that local computer at the moment the user entered the password and clicked to login ?
If the user is accessing the website without using SSL (i.e. by going to "http://" instead of "https://"), then it is possible to see all of the traffic between the website and the browser, and not only on the local computer but also on the network that the computer is connected to.
If the user is accessing the website via HTTPS, Fiddler is able to act as a proxy and decrypt the traffic between the browser and the server by using a special SSL certificate (thanks to #user18044 for clarification in the comments below).
In your case Fiddler is NOT accessing browser memory directly to get to the password in clear text.
We all know that it's bad to transmit usernames and passwords over plaintext, since they can be easily viewed by anybody looking at the packets, so we use HTTPS to encrypt this data.
I've noticed that many websites just use HTTPS for the login form and use regular HTTP for all other pages (such as StackOverflow). Couldn't somebody see the cookie (like a session cookie) returned from a login form and inject that into their own web requests? Although it won't expose the username and password, it seems like they could impersonate another user by doing this.
Let's say I'm snooping into my friend's internet connection. After my friend authenticates in HTTPS, the server and my friend begin communicating over HTTP and transmit the cookies in plaintext. What is preventing me from using this cookie?
Nothing is preventing you from using the cookie and stealing his sessions. It's a very poor security practice to send cookies over HTTP. In fact this very weakness was used by the Firesheep Firefox extension that made headlines a few years ago. Since then some sites (notably Facebook and Gmail) have moved to HTTPS only. Other sites should follow suit.
It is not really. If an attacker steals the cookie and then uses it, this is known as Session Hijacking.
StackOverflow are aware of this problem and have been looking at moving towards HTTPS everywhere (site network wide).
To prevent a cookie from ever being sent over an insecure connection, the Secure flag should be set. This will stop the browser from sending it over HTTP connections, even if an attacker tried to make it leak from their own site (very easy to do, an attacker could just include <img src="http://www.example.com/anything.jpg" /> in their own site to cause an unsecure cookie to be sent over HTTP and conduct a MITM attack).
I was using google SSL search (https:www.google.com) with the expectation that my search would be private. However, my search for 'toasters' produced this query:
https://encrypted.google.com/search?hl=en&source=hp&q=toasters&aq=f
As you can see, my employer can still log this and see what the search was. How can I make sure that when someone searches on my site using SSL (using custom google search) their search terms isn't made visible.
The URL is sent over SSL. Of course a user can see the URL in their own browser, but it isn't visible as it transits the network. Your employer can't log it unless they are the other end of the SSL connection. If your employer creates a CA certificate and installs it in your browser, they could use a proxy to spoof Google host names, but otherwise, the traffic is secure.
HTTPS protects the entire HTTP exchange, including the URL, so the only thing someone intercepting network traffic will be able to determine is that there was communication between the browser and your site (or Google in this case). Even without the innards, that information can be useful.
Unless you have full administrative control over the systems making the queries, you should assume that anything transpiring on them can be intercepted or logged. Browsers typically store history and cache pages in files on the local disk which can be read by administrators. You also can't verify that the browser itself hasn't been recompiled with code to log sites that were visited, even in "private" mode.
Presumably your employer provides you with a PC, the software on it, the LAN connection to its own corporate network, the internet proxy and corporate firewall, maybe DNS servers, etc etc.
So you are exposed to traffic sniffing and tracing at many different levels. Even if you browse to a url over SSL TLS, you have to assume that the contents of your http session can be recorded. Do you always check that the cert in your browser is from google and not your employer's proxy? Do you know what software sits between your browser and your network card, etc.
However, if you had complete control over the client, then you could be sure that no-one external to your https conversation with google would be able to see the url you are requesting.
Google still knows what you're up to, but that's a private matter between your search engine and your conscience ;)
to add to what #erickson said, read this. SSL will protect the data between the connected parties. If you need to hide that link from the boss then disable the browser caching of the sites visited, i.e. disable or delete the history data.
I'm using gmail from work, but I need to enter a password for a proxy when accesing the first web page. The password is asked from inside the browser. I receive a certificate from the proxy which I must accept in order to make the Internet connection work.
Can my HTTPS connection, between gmail and browser, be tracked in this situation?
Fiddler describes it like this:
Q: The HTTPS protocol was designed to prevent traffic viewing and tampering. Given that, how can Fiddler2 debug HTTPS traffic?
A: Fiddler2 relies on a "man-in-the-middle" approach to HTTPS interception. To your web browser, Fiddler2 claims to be the secure web server, and to the web server, Fiddler2 mimics the web browser. In order to pretend to be the web server, Fiddler2 dynamically generates a HTTPS certificate.
Fiddler's certificate is not trusted by your web browser (since Fiddler is not a Trusted Root Certification authority), and hence while Fiddler2 is intercepting your traffic, you'll see a HTTPS error message in your browser, like so:
tracked? Well even though https encrypts the traffic you still know the ip address of both parties (gmail and the browser). HTTPS doesn't solve this problem, but a different blend of crypto has created The Onion Router(TOR) which does make impossible to locate both servers and clients.
Under "normal" conditions when an attacker is trying to MITM HTTPS your browser should throw a certificate error. This is the whole point of SSL backed by a PKI. HOWEVER in 2009 Moxie Marlenspike gave a killer Blackhat talk in which he was able to MITM HTTPS without warning. His tools is called SSLStrip, and I highly recommend watching that video.
A good solution to SSLStrip was developed by Google. Its called STS, and you should enable this on all of your web applications. Currently sts is only supported by Chrome, but Firefox is working on their supporting this feature. Eventually all browsers should support it.
Yes they can. You can see this for yourself by downloading Fiddler and using it to decrypt https traffic. Fiddler issues its own certificate and acts a man in the middle. You would need to view the certificate in your browser to see whether it is actually issued by gmail.
It seems that the renegotiation is a weak spot in the TSLv1 (see TLS renegotiation attack. More bad news for SSL).
As pointed out by other answers (read also here) for this to work really "in the middle" (i.e. excluding the cases in which the capturing occurs at one of the end-points, inside the browser or inside the web server), some kind of proxy must be set, who speaks to your browser and to the server, pretending to both to be the other side. But your browser (and ssl) is smart enough to realize that the certificate that the proxy sends you ("saying: I am gmail") is illegal, i.e. is not signed by a trusted Root Certification authority. Then, this will only work if the user explicitly accepts that untrusted certificate, or if the CA used by the proxy was inserted into the trusted CA registry in his browser.
In summary, if the user is using a clean/trusted browser installation, and if he refuses certificates issued by untrusted authorities, an man "in the middle" cannot decrypt an https communication.
It cannot be tracked between the gmail webserver and your pc, but once it is inside the pc, it can be tracked. I dont understand how two people claim that https can be tracked with mitm since the whole purpose of https is to prevent such attacks.
The point is that all HTTP level messages are encrypted, and mac-ed. Due to the certificate trust chain, you cannot fake a certificate, so it should not be possible to perform a man in the middle.
The ones who claim it is possible, can you please give details about how and why it is possible and how the existing countermeasures are circumvented?