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.
Related
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
I created the server.key and server.csr files using openssl req -nodes -newkey rsa:2048 -keyout server.key -out server.csr. I created a SSL certificate with startssl.com which gave me a certificate file. Then in my node.js application I read the key and certificate files:
var app = module.exports = express.createServer({
key: fs.readFileSync('server.key'),
cert: fs.readFileSync('server.cert')
});
But, now I get an empty response from my application, a "No data received" message. What could be causing this? I'm very new to SSL and how it all works, so any help with this is very much appreciated.
More info: I generated the two files, key and csr files, on my VPS server (production server), and now I'm trying to get them to work on my localhost (firstly, before I commit my code to production; I have to test that it works before making a git commit). So, it could be due to the fact that my localhost (development environment) is on a different domain from my VPS server (production environment). Could this be the case? If so, how can I make it to where the localhost and production environment use the same certificate?
Or, would you suggest I create another certificate for my development environment? The only problem I see with that, is that I wouldn't have a domain for my dev environment because it's done locally. I'd rather much use the same certificate (even if that means a broken lock icon or something on localhost) for the sake of simplicity.
I know this is an old question, but I encountered the same thing today. I would get the same result back from express (ERR_EMPTY_RESPONSE).
The fix? Be sure to specify https, and not http, in your test browser (e.g., https://localhost:8443).
If you previously used middleware to forward all http requests to https you wouldn't have seen this problem before. Also, expect your browser to complain about the certificate, but proceed through anyway (in chrome this takes several clicks).
You can troubleshoot errors by connecting to your application with curl --insecure --verbose. Generally you shouldn't use an SSL certificate on more than one host. You can make a self-signed one to test locally and use the startssl one in production. But in any case, the CN in the cert needs to match the hostname used to connect to the site to avoid annoying browser warnings. You can always make up a domain name for your machine like sam.local and put that in your /etc/hosts file and use that in your self-signed certificate as well as your browser address bar.
In my server I have one SSL Certificate which is valid from 06/09/2009 through 06/09/2011. the client is getting invalid certificate error. I reissued the certificate and installed in the server machine. But still the client is getting the same error. Is there any problem with the Browser. Can anyone reply for this issue. But If I open the page in different machine I can go to the site without any invalid certificate error message.
I have had similar problems self signed certs switching to legit certs. The browser seems to cache the cert (though it shouldn't be browser specific)
I have noticed the problem more in Chrome than other browsers. You can try dumping the cache in the browser. You can also run
certmgr.msc
and see if the expired cert shows up, if it does you should be able to delete it and hit the site again to get the new cert.
My related question on serverfault: https://serverfault.com/questions/279984/clearning-chrome-ssl-cache
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.