I am trying to use hash-buster and making requests from my server to database's of hash-buster.
and each time I get this error:
Hash function : MD5
/usr/lib/python3/dist-packages/urllib3/connectionpool.py:849: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
InsecureRequestWarning
I am new in python 3 also in Ubuntu(19.04). Please help me about adding certificate in my server, actually I need a step by step guide to install and activate it (or whatever).
I found my certifications in my server: (etc/ssl/certs/ca-certificates.crt). Is it possible to use my own certifications?
I hope my questions is clear, please feel free to ask me questions to make it clearer.
I am trying to use hash-buster....
I'm assuming that you mean this project.
... Unverified HTTPS request is being made. Adding
certificate verification is strongly advised. ...
The code contains the following line, which probably is the reason for this warning:
response = requests.get('https://www.nitrxgen.net/md5db/' + hashvalue, verify=False).text
So it is explicitly disabling certificate validation here with verify=False. Given that there are other HTTPS requests in the code and this one is the only one with certificate validation disabled, it is likely to work around a problem with the site.
And, the SSLLabs report for www.nitrxgen.net shows that that the site is not properly configured:
This server's certificate chain is incomplete. Grade capped to B.
This incomplete certificate chain causes requests to fail. To work around the broken site one need to either import the missing chain certificate in the trust store or have it explicitly trusted by the code.
Since there are many similar questions already I don't want to repeat all the details. See for example Python requests SSL error - certificate verify failed
, Python Requests getting SSLerror, SSL error with Python requests despite up-to-date dependencies for more.
Related
I am trying to make something very basic work and it just isn't working for me. I have a simple Node-RED flow with an inject input node and an email output node:
The properties of the email node look like this:
The error says:
"7/28/2017, 11:43:28 AM node: fname.lname#company.com
msg : error
"Error: unable to verify the first certificate"
I am able to manually send unauthenticated email through this server via telnet. Even if I enter account creds it gives me the same "Error: unable to verify the first certificate".
Am I missing something simple?
I don't have enough reputation to write a comment, but i am adding this line for the previous reply, somebody might need it,
to bypass this error in Node.js program, type:
process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0";
The problem is that the mail server you are connecting to is using SSL and the certificate it is supplying is not signed by one of the trusted CA's built into the Node.JS implementation you are using.
I'm guessing it's a self signed certificate.
The Error says that Node.JS can not verify the first certificate in the presented chain.
My best guess is that Nodemailer (which is used under the covers by the email node) is seeing the STARTTLS option listed when it sends the EHLO command as it starts the connection to the mail server and is trying to upgrade the connection to one that is secure.
While I really wouldn't normally recommend this, you can turn off Node.JS's cert checking by exporting the following environment variable before starting Node-RED:
NODE_TLS_REJECT_UNAUTHORIZED=0
This turns off ALL certificate checking, so you are open to man in the middle attacks for any TLS/SSL connection made from Node-RED.
The real solution here is to get a proper certificate for the mail server, maybe something from the letsencrypt project especially if this mail server is internet facing in any way.
This link describes some otpions to fix this problem: https://github.com/PHPMailer/PHPMailer/wiki/Troubleshooting#php-56-certificate-verification-failure
But I simply don't know what to do specifically in Joomla and how to prevent this verification, because I can't set up ssl for my site.
warning:
Warning: stream_socket_enable_crypto(): SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed in /nfsmnt/hosting1_1/1/b/1bec1745-5e90-43d0-beb1-2d132937948b/domain.com/web/libraries/vendor/phpmailer/phpmailer/class.smtp.php on line 344
What is the sense of this verification, when so many websites don't run ssl?
Piece of code in Joomla library (class.smtp.php)
// Begin encrypted connection
if (!stream_socket_enable_crypto(
$this->smtp_conn,
true,
STREAM_CRYPTO_METHOD_TLS_CLIENT
)) {
return false;
}
return true;
}
You are missing the point. It's not the site that's using SSL, it's the mail server you are connecting to. For example if you use PHPMailer to send a message via your gmail account, the connection to gmail will be encrypted, regardless of whether your web server is.
The problem you are running into is that the mail server you are using is misconfigured. If it is advertising encryption to inbound connections, it should use a valid certificate. The error will be that the certificate has expired, is a self-signed certificate (and thus can't be trusted), or does not match the host name that you have connected to. The instructions in the guide tell you how to disable these checks, and they should be applied at the point PHPMailer is used, not by altering the library itself. You can find where to do this in the Joomla code base by searching for instances of new PHPMailer and following it with the code that sets the degraded SSL options in the guide. Bear in mind though that this is the wrong way to fix it. If your mail server can't be fixed, use a proper hosting company that knows what it's doing.
As for "not many sites run SSL", that's just not true. All sites should run SSL, but many do not. There is really no excuse not to now that you can get free real certificates with minimal hassle. For more compelling aguments, read this.
I started fiddler and when I tried to access google.com , I got the below error
It was able to find that, the request is coming from an untrusted tool or something like that. Can anyone please explain how they are doing it or any hint about it, so that, we could apply for our web sites.
Once I closed the fiddler, it started working fine again.
Thanks in advance
Jonathon
It's all explained in the "what does it mean" section: Fiddler has send your browser its own SSL certificate to be able to intercept the request (it –more or less– decrypts it using its certificate, then re-encrypts it using Google's one).
Chrome comes preloaded with public keys that it expects to see in the certificate chain for web sites, including of course google.* ones, so it can detect that Fiddler's certificate is not one coming from Google.
See http://blog.stalkr.net/2011/08/hsts-preloading-public-key-pinning-and.html
I am using the Authorize.Net DPM (Direct Post Method) integration on one particular eCommerce system that I manage.
We have renewed our SSL certificate for this site, and the new SSL cert uses SHA-256 rather than SHA-1, as is recommended for additional security.
However, now AUthoeize.Net can no longer post back to my server. When processing a payment, I receive the message:
An error occurred while trying to report this transaction to the merchant. An e-mail has been sent to the merchant informing them of the error. The following is the result of the attempt to charge your credit card.
from the URL https://secure.authorize.net/gateway/transact.dll, rather than being sent back to my code where I can display the "payment successful" page. Upon reseraching this, I believe the issue is that Authorize.Net's servers don't support SHA-2 certificates:
Does anyone know if Authorize.net accepts the newer SHA2 encryption? Our production servers which use this type of certificate do not receive the RelayResponse.
We found an article on SHA2 encryption issues with WIN2003 servers KB968730. We know Authorize.net uses Win 2003 servers based on http headers, which tell us IIS6.0.
We just established that is a real issue with Authorize.Net. We were able to purchase a SHA1 certificate and we are now able to receive the Relay Response from Authorize.NET. Authorize.NET Relay Response does not handle G2/SHA256 certificates. This will become a major issue in 2014 when SHA1 certifictions will not be obtainable from vendors eg. GoDaddy etc.
I have contacted Authorize.Net support but they seem to not even understand how their own product works, because the responses I get from them make no sense:
We have no announcements regarding the use specifically of SHA-2 hashes to connect to our servers at this time. Notices of any changes to the integration methods will be available in the merchant interface, as well as on the developer center at developer.authorize.net if that change occurs.
I'm not connecting to their servers. They're connecting to my server... so since their support is of no help... how can I resolve this? Is it safe/wise to not use SSL for the x_relay_url DPM postback URL? That seems to be the safest suggestion but I am hesitant to do this.
The resolution I went with was to get an SSL certificate with an SHA-1 signature algorithm, rather than SHA-2.
The issue that SHA-2 certs are rejected by Authorize.net's servers has been reported to their systems engineering team, but I do not know if they will correct this.
I have just run into this problem myself.
I can verify that in my tests, when I switched my x_redirect_url parameter to use a non-ssl host it started redirecting properly back to my site. I can also verify that Authorize.net support does not know how their own products work; I had to explain to them how the x_redirect_url works and got no usable info from them regarding any kind of validation they might be doing on the redirect URL that could cause their system to refuse to redirect.
I thought it was due to a domain name mismatch in my dev environment so I just forced my dev environment to use a non-ssl redirect. Then when I launched my new site I discovered that the problem persisted with SSL redirects on my production site, so I've just switched it back to using non-ssl redirects on my production site temporarily until I get this sorted out.
I have not yet regenerated my ssl cert because I'm not sure if it's using SHA1 or SHA2 and I don't want to regenerate it and reinstall it until I'm sure the cert is SHA1.
I'm having a hard time determining which SHA version it uses because the Thumbprint Algorithm shows SHA1, but then I see SHA256RSA for the Signature Algorithm and sha256 for the Signature Hash Algorithm. So, if anyone knows if that means I have SHA1 or SHA2, please reply to this reply.
I want to ensure that client libraries (currently in Python, Ruby, PHP, Java, and .NET) are configured correctly and failing appropriately when SSL certificates are invalid. Shmatikov's paper, The Most Dangerous Code in the World:
Validating SSL Certificates in Non-Browser Software, reveals how confusing SSL validation is so I want to thoroughly test the possible failures.
Based on research a certificate is invalid if:
It is used before its activation date
It is used after its expiry date
It has been revoked
Certificate hostnames don't match the site hostname
Certificate chain does not contain a trusted certificate authority
Ideally, I think I would have one test case for each of the invalid cases. To that end I am currently testing an HTTP site accessed over HTTPS, which leads to a failure that I can verify in a test like so:
self.assertRaises(SSLHandshakeError, lambda: api.call_to_unmatched_hostname())
This is incomplete (only covering one case) and potentially wrong, so...
How can you test that non-browser software properly validates SSL certificates?
First off, you'll need a collection of SSL certificates, where each has just one thing wrong with it. You can generate these using the openssl command line tool. Of course, you can't sign them with a trusted root CA. You will need to use your own CA. To make this validate correctly, you'll need to install your CA certificate in the client libraries. You can do this in Java, for example, using the control panel.
Once you have the certificates, you can use the "openssl s_server" tool to serve an SSL socket using each one. I suggest you put one certificate on each port.
You now have to use the client library to connect to a port, and verify that you get the correct error message.
I know that Python by default does no certificate validation (look at the manual for httplib.HTTPSConnection). However, m2crypto does do validation. Java by default does do validation. I don't know about other languages.
Some other cases you could test:
1) Wildcard host names.
2) Certificate chaining. I know there was a bug in old browsers where if you had a certificate A signed by the root, A could then sign B, and B would appear valid. SSL is supposed to stop this by having flags on certificates, and A would not have the "can sign" flag. However, this was not verified in some old browsers.
Good luck! I'd be interested to hear how you get on.
Paul
Certificate hostnames don't match the site hostname
This is probably the easiest to check, and failure (to fail) there is certainly a good indication that something is wrong. Most certificates for well-known services only use host names for their identity, not IP addresses. If, instead of asking for https://www.google.com/, you ask for https://173.194.67.99/ (for example) and it works, there's something wrong.
For the other ones, you may want to generate your own test CA.
Certificate chain does not contain a trusted certificate authority
You can generate a test certificate using your test CA (or a self-signed certificate), but let the default system CA list be used for the verification. Your test client should fail to verify that certificate.
It is used before its activation date, It is used after its expiry date
You can generate test certificates using your test CA, with notBefore/notAfter dates that make the current date invalid. Then, use your test CA as a trusted CA for the verification: your test client should fail to validate the certificate because of the dates.
It has been revoked
This one is probably the hardest to set up, depending on how revocation is published. Again, generate some test certificates that you've revoked immediately, using your own test CA.
Some tools expect to be configured with a set of CRL files next to the set of trusted CAs. This requires some setup for the test itself, but very little online setup: this is probably the easiest. You can also set up a local online revocation repository, e.g. using CRL distribution points or OCSP.
PKI testing can be more complex than that more generally. A full test suite would require a fairly good understanding of the specifications (RFC 5280). Indeed, you may need to check the dates for all intermediate certificates, as well as various attributes for each certificate in the chain (e.g. key usage, basic constraints, ...).
In general, client libraries separate the verification process into two operations: verifying that the certificate is trusted (the PKI part) and verifying that it was issued to the entity you want to connect to (the host name verification part). This is certainly due to the fact these are specified in different documents (RFC 3280/5280 and RFC 2818/6125, respectively).
From a practical point of view, the first two points to check when using an SSL library are:
What happens when you connect to a known host, but with a different identifier for which the certificate isn't valid (such as its IP address instead of the host)?
What happens when you connect to a certificate that you know cannot be verified by any default set of trusted anchors (for example, a self-signed certificate or from your own CA).
Failure to connect/verify should happen in both cases. If it all works, short of implementing a full PKI test suite (which require a certain expertise), it's often the case that you need to check the documentation of that SSL library to see how these verifications can be turned on.
Bugs aside, a fair number of problems mentioned in this paper are due to the fact that some library implementations have made the assumption that it was up to their users to know what they were doing, whereas most of their users seem to have made the assumption that the library was doing the right thing by default. (In fact, even when the library is doing the right thing by default, there is certainly no shortage of programmers who just want to get rid of the error message, even if it makes their application insecure.)
I would seem fair to say that making sure the verification features are turned on would be sufficient in most cases.
As for the status of a few existing implementations:
Python: there was a change between Python 2.x and Python 3.x. The ssl module of Python 3.2 has a match_hostname method that Python 2.7 doesn't have. urllib.request.urlopen in Python 3.2 also has an option to configure CA files, which its Python 2.7 equivalent doesn't have. (This being said, if it's not set, verification won't occur. I'm not sure about the host name verification.)
Java: verification is turned on by default for both PKI and host name for HttpsUrlConnection, but not for the host name when using SSLSocket directly, unless you're using Java 7 and you've configure its SSLParameters using setEndpointIdentificationAlgorithm("HTTPS") (for example).
PHP: as far as I'm aware, fopen("https://.../") won't perform any verification at all.