My understanding of HTTPS is that the encryption and decryption is done in the process, and any data that passes through the OS is encrypted.
Most HTTPS MITM tools work by editing the HTTPS client to send requests via a proxy, and/or accept invalid SSL certificates.
Given:
Program A is a binary program that contains an HTTPS client (that does not use a proxy and only accepts valid SSL certs).
Program A cannot be modified.
The OS can be modified, instrumented etc.
Would this mean the responses processed by the program have definitely come from the server and are not modified?
Does HTTPS have protection for replay attacks (sending the same encrypted response that was recorded earlier)?
Given:
Program A is a binary program that contains an HTTPS client (that does not use a proxy and only accepts valid SSL certs).
Program A cannot be modified.
The OS can be modified, instrumented etc.
The question is, what are valid SSL certificates, how does the browser know? Firefox has its own certificate store, but Google Chrome uses the OS certificate store (they are creating thier own certificate store). Firefox however, does not load the OS certificate store by default. So your reasoning holds up for some browsers.
Being able to edit the trusted certificates on browsers is used, quite extensively, on intranet sites by corporations, so they don't have to get their certificates signed by a trusted third party.
As for your last question, https://security.stackexchange.com/questions/20105/are-ssl-encrypted-requests-vulnerable-to-replay-attacks explains this very well.
Sources:
https://www.zdnet.com/article/chrome-will-soon-have-its-own-dedicated-certificate-root-store/
https://support.mozilla.org/en-US/kb/setting-certificate-authorities-firefox
Related
Suppose I have valid HTTPS page https://mydomain.tld (letsencrypt certificate in this case) and I want to display images from some other domain mystatic.tld.
I’m aware that it is not possible to use HTTP content http://mystatic.tld, because browsers will block it.
What about if mystatic.tld is using a self-signed certificate? When opening a web page from that server, most modern browsers will give a warning and require the user the manually accept the security implications afaik. What happens to images embedded inside my original page from mydomain.tld?
I have a NodeJS server on Amazon EC2.
I'm trying to set up SSL using certificates from "COMODO RSA Domain Validation Secure Server CA".
I got it working for all browsers except Firefox. Is this a common issure?
Please check that the server provides all intermediate certificates (trust chain). A common issue is to forget the intermediate certificates and then get errors on some browsers an no errors on others. This is caused by the browsers caching the intermediate certificates, e.g. if you've visited a site using the same intermediate certificates before, the browser will dutifully use these cached intermediates if the server forgot to server them. But, if the browser never visited such site before the intermediates are not cached and thus the verification will fail.
A good test is to use openssl s_client -connect your.https.server:443 and look at the chain of certificates it provides. Also, https://www.ssllabs.com/ssltest/analyze.html will point out such problems.
Just want to verify, when making a SSL connection (http post) to say:
https://www.example.com/some/path?customer_key=123123123
If you don't want anyone to know about customer_key, this approach will not work even if I am making a https connection correct?
All data that I want secured has to be in the request body right?
Quoting the HTTPS RFC:
When the TLS handshake has finished. The client may then initiate the
first HTTP request. All HTTP data MUST be sent as TLS "application
data".
Essentially, the secure SSL/TLS channel is established first. Only then the HTTP protocol is used. This will protect all the HTTP traffic with SSL, including HTTP headers (which contain the URL and cookies).
What may be visible in the handshake is the host name itself, since it's contained in the server certificate which will be visible in clear in the handshake (and it's often easy to guess the host name by looking at the destination IP address anyway).
When using Server Name Indication, the requested host name should also be visible in the server_name extension in the ClientHello message.
Otherwise, there may be a bit of ambiguity (for the eavesdropper) to guess the host name from the certificate if the certificate is valid for multiple host names (e.g. multiple Subject Alt. Names or wildcards). In this case eavesdropping the DNS request from the client might give the attacker a clue.
Reading other people's answers and comments, some mention issues about Referer (lost an r in the spec) and logs.
Referrers shouldn't be sent when going from HTTPS to HTTP (but they are often sent when going from one HTTPS site to another HTTPS site).
About the history: you'll just have to trust whoever can potentially get that key legitimately (i.e. your users) not to spread it around. If needed, have a strategy to change it once in a while.
About the logs: I was assuming you were after protection over the network. The URL (including query) will be in the logs indeed, but if someone is able to attack your machine so as to get the logs, you have more to worry about that your app keys.
One of the remaining potential weak points is how you give that link to the user. If it's embedded in a web-page served over plain HTTP, anyone who can read that page would be able to see it. You should serve such a page over HTTPS too. If you send that link by e-mail instead, I'd say all bets are off, since mail servers rarely encrypt the connections between themselves and users also often to access their e-mail account without any encryption.
EDIT:
In addition, if you're using client-certificate authentication, the client certificate will be visible if it is negotiated during the initial handshake. This may leak the name of the user accessing the website (often Subject DNs contain the user name). The client certificate will not be visible if it is sent during a re-negotiated handshake.
Only www.example.com will be visible to snoopers. The path section of the request is protected by SSL/TLS.
Obviously, you need to have sent original the hyperlink by HTTPS, too.
Request data will be sent after establishing Secure connection, so no worries with above URL, but remember your data is not encrypted, only channel between server and client is encrypted, if one can crack this channel, then can clearly see your data.
SSL is wrapper encrypted channel on top of your data. If data is plain, anyone who can crack the SSL can see your data clearly.
Revising my answer to NO!
Apparently only the host name is sent in clear text before the SSL connection is established.
http://answers.google.com/answers/threadview/id/758002.html
That Depends..
If you use a packet sniffer you cannot see the data sent over the wire. The main problem with this approach is that the request url is often saved in the server's log in plain text, the browser history keeps the url, URLs are passed in Referrer headers and maybe persisted by third party services (google analytics).
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?
my question is related to hypertext protocol.
what is the requirements from my side to be able to use HTTPS instead of HTTP in the areas where a user will enter confident information or when there is a registration process.
Thank you.
You need a certificate (you can buy one, which are usually identified by browsers, or create a self-signed certificate, which will trigger a warning on browsers) and a server able to run HTTPS. HTTPS capable servers allow you to define which pages are served via HTTP and which via HTTPS.
HTTPS IS NOT authentication, by the way, it only encrypts communications to prevent eavesdroppers reading what's being sent between the server and client.
You can use any authentication method over HTTPS, but you need to provide it (be it HTTP Auth or something in your application.)
There isn't much more to say given your ambiguous question.
Primarily, you need to configure your webserver to use https; this in turn requires that you have a server certificate. You can either create your own server certificate, or you can buy one from one of the Certificate Authorities. The latter will cause browsers to trust that your site is genuine (whereas in the case of one that you created yourself, a man-in-the-middle or phishing attack might happen from the viewpoint of the browser).
How to configure your server precisely should be discussed on serverfault.