In my work computer, Firefox always gives me the "sec_error_unknown_issuer" error. This happens only on all HTTPS sites.
I have browsed Mozilla's support forums and understood that this is most probably caused by a software that performs an HTTPS scanning. The software presents its "fake" certificates to Firefox and hence, Firefox says that it does not know the issuer of these certificates.
However, I don't know which software is performing the HTTPS scanning and presenting its "fake" certificates to Firefox.
Is there a way to determine which software is performing the HTTPS scanning so that I will be able to add its certificates to Firefox and hence, be able to use the Firefox properly?
In my work computer,...which software is performing the HTTPS scanning
This is probably legal SSL interception done by a firewall in your company. If you want to know the exact software used for scanning ask your local network administrator.
... so that I will be able to add its certificates to Firefox and hence, be able to use the Firefox properly?
If you look at what certificates your server sends you have a look at the certificate details in the browser, especially at the chain certificates. But to make sure that what you get is really the companies certificate used for SSL interception and not some malicious man-in-the-middle attack you should verify your finding with your network administrator. And I'm pretty sure that if they do legal SSL interception they also help you do add the certificate to your browser - at least as long you are allowed to install alternative browsers to your computer and/or your own computer to connect to the companies network.
Related
Recently I found myself working with Guzzle while making requests to another server to post and fetch some data, in some cases, tokens. But I was getting certificate invalid error and I even tried to get a new .pem certificate, but Guzzle was still not accepting and kept throwing that error. So finally, I did what the "Internet" said:
$guzzleClient = new Client([
'verify' => false
]);
Now although this solution works, I am not sure how insecure it can get. Do I need to worry? If yes, in what scenarios?
well this is a big problem if you are for example
having login system on the request you are sending using guzzle
having payment/checkout on the request
basically any sensitive data being passed to the other server
because when you pass data without SSL certificate then your requests might get caught by malicious programs like
BurbSuite / WireShark , cain and abel / EtterCap
as these programs are Sniffing programs and anyone can get a version from the internet as they are open sourced and every thing going without SSL can be intercepted by the hacker using the tools mentioned above and the hacker can look to the entire request in plaintext! so its highly recommended to use SSL connection when passing sensitive data
Worth Mentioning : now a days even SSL isn't very secure because hackers can remove it using SSLStrip tool but believe me SSL will make it much harder for them to get to your request because if they used it your website sometimes will make non-completed requests and it will notify the user that the network isn't secure this will make it very hard for the hacker to get the user's data,
TLS/SSL in common configurations is meant to give you three things:
confidentiality - no third party is able to read the messages sent and received,
integrity - no third party is able to modify the messages sent and received,
server authentication - you know who are you talking to.
What you do with setting verify to false is disabling the certificate verification. It immediately disables the server authentication feature and enables loosing confidentiality and integrity too when facing an active attacker that has access to your data stream.
How is that?
First of all TLS/SSL relieas on Public Key Infrastructure. Without going into too much details: you hold on your machine a set of certificates of so called Certification Authorities (CA) whom you trust. When you open a new communication to a service, you get the services certificates and in the process of verification you validate amongst other things if the certificate belongs to a CA you trust. If yes, then the communication may proceed. If no, then the communication channel is closed.
Attack patterns
Disabling certificate verification allows for Man-in-the-Middle (MitM) attacks than can easily be performed in your local network (e.g. via ARP poisoning attacks), in the local network of the service you are calling or in the network between. As we usually do not trust the network completely, we tend to verify.
Imagine me performing an attack on you. I have performed ARP poisoning, now I can see all your traffic. It's encrypted, isn't it? Well, not obviously. The TCP handshake and TLS handshake you believe you have performed with the target service - you have performed with me. I have presented you not the certificate of the target service, as I am unable to fake it, but my own. But you did not validate it to reject it. I have opened a connection between me and the target service on your behalf too so I can look into the decrypted traffic, modify if necessary and reply to you to make you believe everything is ok.
First of all - all your secrets are belong to me. Second of all - I am able to perform attacks on both you and the target service (which might have been secured by authentication mechanisms, but now is not).
How to fix this?
In XXI century there should be little reason to disable TLS verification anywhere. Configuring it to work properly might be a pain though, even more when you are doing it for the first time. From my experience the most common issues in the micro service world are:
the target certificate is self-signed,
you are missing a CA root certificate in your trust store,
the microservice does provide his certificate, but does not provide an intermediate CA certificate.
It's hard to guess what your issue is. We would need to dig deeper.
While the other answers points out some really good point about how important SSL/TLS is, your connection is still encrypted and the remote endpoint you're using has https:// in it as well. So you're not entirely disabling SSL when you set verify to false if I'm not mistken. It's just less secure since that you're not verifying the certificate of the remote server if they are signed by a Certificate Authority (CA) using the CA bundle.
Do you need to worry?
If this is something on your production, ideally you'd want things to be secure and configured correctly, so yes.
By not verifying the certificate, like Marek Puchalski mentioned, there's possibility of the server might not be the one you think it is and allows mitm (man in the middle) attack as well. More about mitm here, and peer verification here.
Why is it happening & how do you fix it?
Most common issue is misconfigured server, especially PHP configuration. You can fix your PHP configuration following this guide, where you'll be using adding the CA root certificates bundle to your configuration. Alternatively you can add this to Guzzle.
Another common issue is, the remote server is using a self-signed certificate. Even if you configured your CA bundle in your trustedstore, this certificate can't be trusted since it's not signed by a trusted CA. So the server needs to configure a SSL certificated signed by a CA. If that's not possible, you can manually trust this CA root, however this comes with some security concerns as well.
Hope this helped :)
I have the following scenario:
A network will be set up on a Windows infrastructure
A website will be put on that network - It is not given a domain name and is not available on the internet. It will be addressed only via an internally recognised IP address.
A piece of software within that network will communicate with the website
(we want to avoid the 'Could not establish trust relationship issue' found with self-signed certificates without reducing security as, I believe, the accepted answer does).
The website will also be viewed on tablets and PCs.
After a few days, the service will be be put on a different network (with different IPs).
It will installed on many PCs/Networks.
I want to secure this via SSL, but it seems tricky following the 2015 update that disallowed IP addresses to have certificates.
This post suggests going via a public IP, but the solution may be completely offline in an area without internet access.
I've spent hours researching, but seem to be missing something.
How should this be done please?
I would setup a DNS server with an app.local domain that gets issued the certificate.
Even if you serve up the intermediate certificates in the TLS handshake (which you should ALWAYS do and not rely on AIA), verifying the chain becomes problematic without Internet access as browsers won't be able to reach the CRL URL (Certificate Revocation List). That is, of course, unless we're talking about your own CA (living in the same network) that issues the site certificate.
If everything you describe runs in a well guarded sandbox then you probably don't need the TLS layer at all, ask yourself WHO is the attacker and WHAT are you protecting.
I've been struggling recently with using the standalone DartVM and SSL as a client. I'm of the understanding that Dart uses Mozilla NSS to manage the certificates. What I'm having a problem wit, is that on Windows, for example, there exists no binaries that I can find (other than third parties compiling the Mozilla source and uploading to mega or similar, which is pretty alarming if you ask me) released for the Windows platform. Compiling this C++ code is not a trivial task. I've not the resources to do so on my own under the Windows platform. This is why I write Dart (or other high level languages) in the first place.
Despite that, the error message I get when attempting to connect securely and being presented with a self-signed (or rather more technically correct, untrusted authority) certificate, is that the OS itself doesn't trust the certificate. On Windows, this is not the case. The certificate in question I'm using is a CA root certificate of my generating, with proper authority/signing chain, installed into Windows trusted roots manually. Both Chrome and Internet Explorer (of which use the Windows underlying certificate store) trust my certificate(s) without any warnings after having done this. So if the DartVM is not using the "OS" to validate a certificate upon handshake, then that message is very uninformative/misleading.
What can be done to overcome this outside of compiling NSS and trying to figure out just how to import my certificates by way of over-complicated and under-documented steps? Is there not a parameter that one could specify when initiating a secure connection to ignore SSL errors of this nature?
My web server forces the use of HTTPS so dropping back to plain HTTP would
not be an option for me. I also don't want to trust and much less want to pay a third party for my certificates of which are pretty much only used internally, which is why I generated a wildcard certificate under my own root CA in the first place. Paying for a wildcard certificate, for multiple domains, that aren't always necessarily exposed to the public or meant for public use is a bit astronomically priced and completely out of the question.
Someone please please tell me this is not correct. Reading this link, seem like one can de-crypted https traffic via fiddler. Does it mean if I am doing online banking via https, someone who can intercept this traffic can read my account and pin key information?
Fiddler requires you to install a special SSL root certificate for it to be able to listen to HTTPS traffic. Once you install it, Fiddler can install itself as a proxy (middleman), faking that it's every HTTPS site on the Internet. In short, yes, it can listen to everything over HTTPS, but you need to manually install the certificate on your machine first to allow it.
In theory, any root certificate you install on your machine - Fiddler or not - will allow the person generating it to impersonate any Internet site, so never do it without considering the ramifications.
In SSL terms, what Fiddler does is that it installs itself as a certificate authority on your machine. When you access a HTTPS site for which it is acting as middleman, it quickly generates a certificate claiming to be the site in question. Since the root certificate is on your machine, it will trust Fiddler's certificate and happily let it decrypt everything.
Fiddler will act as a Man in the Middle, using its own SSL certificate, and thus triggering browser warnings. If you are suitably deterred by those warnings, nobody will snoop on your online banking sessions.
For more on how this works, you can read about public-key cryptography.
You have to accept the ssl certificate issued by fiddler but yes you can monitor ssl traffic with fiddler. If you dig a bit deeper there are more sophisticated tools for MITM attacks like: https://www.owasp.org/index.php/Category:OWASP_WebScarab_Project
I'm running mitmdump (from mitmproxy) on my Macbook Pro, and I'm connecting to the proxy through my Windows desktop PC.
However, Chrome (running on the PC) refuses to connect to so many sites because of the invalid certificates which mitmproxy provides.
Chrome throws the error: ERR::NET_CERT_AUTHORITY_INVALID
Here's what mitmdump shows:
But why? What's wrong with mitmproxy's certificates, why can't it just send back google's as if nothing happened?
I'd like to know how I can fix this and make (force) my desktop PC to connect to any website through my Macbook's mitmproxy.
Answering this question for people who may find this important now. To get the proxy working, you have to add the certificate as trusted in your browser.
For windows follow this: https://www.nullalo.com/en/chrome-how-to-install-self-signed-ssl-certificates/2/
For linux follow this: https://dev.to/suntong/using-squid-to-proxy-ssl-sites-nj3
For Mac-os follow this: https://www.andrewconnell.com/blog/updated-creating-and-trusting-self-signed-certs-on-macos-and-chrome/#add-certificate-to-trusted-root-authority
There are some additional details in the above links; tldr; import the certificate in your chrome://settings url and add the certificate as trusted. That shall do.
This will make your browser trust your self-signed certificate(mitm auto generated certificates too.)
The default certificates of mitmproxy is at ~/.mitmproxy/ directory.
Per the Getting Started page of the docs you add the CA by going to http://mitm.it while mitmproxy is running and selecting the operating system that you are using. This should solve your problem and will allow https sites to work with mitmproxy.
This is the expected behavior.
mitmproxy performes a Man-In-The-Middle attack to https connections by providing on-the-fly generated fake certificates to the client while it keeps communicating to the server over fully encrypted connection using the real certificates.
This way the communication between client and proxy can be decrypted. But the client has to actively approve using those fake certificates.
If that wasn't the case then SSL would be broken - which it isn't.
The whole story is very well explained here:
http://docs.mitmproxy.org/en/stable/howmitmproxy.html