I'm using BURP and I always get this alert after a while (maybe like 2-3 minutes of use)
javax.net.ssl.SSLHandshakeException: server certificate change is restrictedduring renegotiation
any idea where that could come from? I don't see anyone talking about it on internet
You're having the exact same issue that has been asked previously: What means "javax.net.ssl.SSLHandshakeException: server certificate change is restrictedduring renegotiation" and how to prevent it?
In short the issue is due to security controls in the newer Java versions that check whether the certificate that it received for the hostname has the same contents (Subject, Issuer, SANs) as the one it previously received.
This has to do with newer versions of Java with older versions (or the free version) of Burp Suite, and using an upstream proxy. Burp Suite Pro v1.6.07+ fixes this, as well as turning off the upstream proxy or downgrading your Java (though not recommended).
Related
Please bear with me. I'm no SSL encrpytion expert. I just want to make connections to a server, using their API. I am unable to. When I use this api as indicated in the documentation, the following error occurs:
[Errno 1] _ssl.c:510: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
This API seems to be hosted on an AWS server somewhere, and the support person for it has referred me to this AWS document with the added information that their server uses TLSv1_2016. I'm not sure that that's correct, but that's what I was told.
This version of TLS is not supported by the OpenSSL that ships with Ubuntu 14.0.4 (openssl v1.0.1f). Version 1.2 IS supported. I upgrade my system on a regular basis, and it doesn't seem that there is any approved Ubuntu release that supports this protocol. I've been advised to upgrade, but it's not clear to what.
This is all Greek to me. Can someone tell me what upgrade I might be able to do my system to solve this?
UPDATE problem persists after installing Ubuntu-18.04, which comes with openssl 1.1.0g.
Answer mostly from comments.
The problem is apparently that the server, like many SSL/TLS servers today especially those handling multiple domains like Cloudfront, requires the SNI (Server Name Indication) extension in SSL/TLS. This was (and easily is) checked with openssl s_client which (unlike most programs) has an option that controls whether to send SNI.
You didn't previously say that this code is Python. It is Python that links to and invokes OpenSSL. (The OS is not involved in SSL/TLS, only in the lower-level TCP/IP protocols.) According to http://docs.python-requests.org/en/master/community/faq/ (at the bottom)
Python3 and Python 2.7.9+ include native support for SNI in their SSL modules. For information on using SNI with Requests on Python < 2.7.9 refer to this Stack Overflow answer.
linking to using requests with TLS doesn't give SNI support which has several answers that appear to consist mostly of updating various things (and I am not in a position to test even if you gave details of your Python and Requests which you didn't).
I'm trying to use a cfhttp post to secure.authorize.net/gateway/transact.dll, but am getting a connection failure. I'm using coldfusion 2016 on windows server 2008. I believe I have the correct cert file registered in the java keystore but am not 100% sure. Based on some google searches, I think that is the problem.
I downloaded and registered GeoTrust Primary Certification Authority - G2 from https://www.geotrust.com/resources/root-certificates/
Any tips on how to make sure the proper sha-2 certificate is registered in the keystore? I tried using IE to save the certificate from secure.authorize.net/gateway/transact.dll, by following the instructions here https://www.youtube.com/watch?v=ewT4aud-xww but that also didn't seem to work.
I should add that this wasn't working even before the TLS disablement date of yesterday. That was just a coincidence. I previously had CF 9 installed, and it was working on there. From what I've always understood, the communication failure error usually indicates lack of or incorrectly imnported certifcate into the keystore. I tried copying the CACerts file from the cf9 instal, as well as start fresh and manually import the certs.
It's likely to be related to the disablement of TLS 1.0 and 1.1 which happened today.
We're having the same issue on a couple of servers, but not others, so trying to work out why that is.
All servers are TLS 1.2 enabled, but connections on some appear to be failing.
Background: I'm a complete newbie when it comes to certificates.
We have a site running at https://global.projacked.com
The certificate is issued by AWS.
All works well for most of our customers but...
One of them is experiencing the following:
And when I click on "view certificate" I see:
So the question is: can we do anything on our end to make this work?
If not: what can I tell my customer to do to make it work? Is it a question of them updating their certificate? Or might it be cause by them being in a secured network (e.g. VPN)?
Thank you immensely in advance for your help
Your site global.projacked.com is serving a valid SHA-256 certificate. The customer who has reported this issue appears to be having its HTTPS traffic intercepted and inspected by some sort of a MITM software or device (the Issuer -- apotex-CA -- on the certificate they're seeing gives it away). The MITMing entity is generating a certificate that is trusted by the customer's browser but it happens to be a SHA-1 certificate causing Chrome to complain.
You cannot do anything to fix their issue. A lot of MITM software vendors have released updates that create SHA-256 certificates to avoid situations such as this. They can probably check to see if there are updates they can install that generate SHA-256 certificates or read this or this to see if they really need to have TLS traffic intercepted and inspected. Sadly, I've seen organizations where the "solution" to this issue is to install an older version of Chrome that did not care about SHA-1 certificates and disable auto-update. After all, burying your head in the sand is very good at blocking all the noise about this little thing called security.
The certificate issuer should be able to issue a certificate under SHA-256. You'll then need to replace the certificate on the server.
Some certificate authorities can give you new cert as a re-issue of the old one, some will require CSR (Certificate Signing Request) that can be constructed based on the existing private key, which likely resides on the server too.
I am using echo_server_tls example with Chrome client. It works fine when I add the certificate to "Trusted Root Certificate Authorities" in certmgr. But if the certificate is not added there, the connection fails silently.
How can I ask user to accept my certificate in case of "Certificate Authority" error?
My OS is Windows 7
You can't do anything once the certificate error is encountered... it's a security feature. What you can do, however, is instruct users before they attempt to use your server that they must install your root certificate. One possible solution is to have them go to an "insecure" (unencrypted) site where the instructions are, then proceed to the "secure" site.
As a side note, buying a real "signed-by-well-known-authority" certificate is not difficult nor expensive... the cost is far less then the trouble of dealing with self-signed certificates in nearly all scenarios.
OK, solved the problem by setting an http handler using set_http_handler().
Thanks
I keep getting Connection Failed when trying to request data from a page that is on an https:// domain. I did install the ssl cert using the built-in section of the railo admin at https://[mydomain]/railo-context/admin/server.cfm?action=services.certificates however I still get Connection Failed. How should I go forward with debugging this? I have confirmed that this server in particular does have access to the domain I am trying to request from.
You probably need some additional certs installed as Jason has said. Take a close look at the cert and it's chain. Go to the cert issuers site and look for some documentation.
To troubleshoot you can add some logging to your jvm args. I think it's something like:
-Djavax.net.debug=all
The results are either in the OUT log or the server.log. This post on SSL 3.0 has some debugging tips. It's possible that your cert needs to handshake at a lower security level than CF allows (SSL 2.0 instead of 3.0/TLS for instance) and that could cause this behavior - but it's more likely that you simply need an intermediate cert installed.
The problem ended up being the permissions weren't setup properly on the machine. After we had the server administrator fix our permissions to access the Railo-Tomcat Service Control, the requests started working. I'm assuming he fixed some other permissions while he was in there.