SSL Certificate are wrongly rejected #5
Comments
|
Mmmh. HTTPS has continuously this kind of problems—the library is set to very tight security, while browsers are, as always, forgiving. I guess there's an HTTPClient parameter to disable this check... |
|
So after digging around, it may be actually related to Java version and LetsEncrypt certs : https://stackoverflow.com/questions/34110426/does-java-support-lets-encrypt-certificates Except that the affected sites do not seem to be using these certificates. Anyway I think it would be a good idea to find a setting that disables SSL verification. |
|
More tips here :
I think the problem is with the getDefaultHostnameVerifier : it probably is the Strict Version : Probably should take the NoopHostnameVerifier or at least the BrowserCompatHostnameVerifier |
|
Here is a code that seems to work (in FetchingThread) : /** An SSL context that accepts all certificates */
private static final SSLContext TRUST_ALL_CERTIFICATES_SSL_CONTEXT;
static {
try {
TRUST_ALL_CERTIFICATES_SSL_CONTEXT = SSLContexts.custom().loadTrustMaterial(null, new TrustStrategy() {
public boolean isTrusted(X509Certificate[] arg0, String arg1) throws CertificateException {
return true;
}}).build();
}
catch (Exception cantHappen) {
throw new RuntimeException(cantHappen.getMessage(), cantHappen);
}
}
/** A support class that makes it possible to plug in a custom DNS resolver. */
protected static final class BasicHttpClientConnectionManagerWithAlternateDNS
extends BasicHttpClientConnectionManager {
static Registry<ConnectionSocketFactory> getDefaultRegistry() {
// setup a Trust Strategy that allows all certificates.
//
SSLContext sslContext = TRUST_ALL_CERTIFICATES_SSL_CONTEXT;
return RegistryBuilder.<ConnectionSocketFactory> create()
.register("http", PlainConnectionSocketFactory.getSocketFactory())
.register("https",
new SSLConnectionSocketFactory(sslContext,
new String[] {
"TLSv1.2",
"TLSv1.1",
"TLSv1",
"SSLv3",
"SSLv2Hello",
}, null, new NoopHostnameVerifier()))
.build();
}
public BasicHttpClientConnectionManagerWithAlternateDNS(final DnsResolver dnsResolver) {
super(getDefaultRegistry(), null, null, dnsResolver);
}
} |
|
OK. I think we should add a parameter here—there are possibly security risks involved. But I agree, the more we are compatible, the better. |
|
Agreed, however, allowing for self-signed certificates is in itself sufficient for totally blowing up SSL security, unless you have pinned the certificates beforehand. |
|
Another problem occurs but it's probably related to java bugs : |
|
I see. Did you check whether https://www.superprof.fr/cours/toute-matiere/marseille/ does work when addressed directly (i.e., not through redirects)? |
|
The problem is the inherited methods are logged with the base class. Try this: |
|
Hi, yes I checked that's why I removed my comment, the problem is not that the ConnectionManager is ignored, just that this particular SSL connection fails, wether it's from a redirect or not. It's probably a java bug, I'll have to dig deeper to correct this. |
|
So, after a bit more digging, it seems that the problem is that, for some reason, the SSL layer tries to initiate a SSLv2 handshake with some sites, and they reply harshly. Removing SSLv2 from the list of supported protocols in the ConnectionManager constructor alleviates the problem (there are still some sites in error though). However I guess that this protocol was added to support some sites ? As a consequence, the only way, in my opinion, to deal with the problem would be to have several connection managers with different supported protocols, catching SSL exceptions and retrying with another Cx Manager when they happen. |
|
Well, I think I copied that list of protocols somewhere, to include all protocols. We might make that list an optional parameter, too. But how many sites would be affected by this? |
|
Maybe a hint in this blog post : https://jve.linuxwall.info/blog/index.php?post/TLS_Survey It's not recent but probably interesting though. |
|
Default is now to accept all certificates; an option brings back the previous behaviour. |
I have this error regarding SSL Certificates, that occurs very frequently :
javax.net.ssl.SSLPeerUnverifiedException: Certificate for <www.genopole.fr> doesn't match any of the subject alternative names: [join-the-biocluster.genopole.fr, jointhebiocluster.genopole.fr, join.genopole.fr] at org.apache.http.conn.ssl.SSLConnectionSocketFactory.verifyHostname(SSLConnectionSocketFactory.java:467) at org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:397) at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:355) at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142) at org.apache.http.impl.conn.BasicHttpClientConnectionManager.connect(BasicHttpClientConnectionManager.java:323) at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:381) at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:237) at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185) at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89) at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:111) at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:72) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:221) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:191) at it.unimi.di.law.bubing.util.FetchData.fetch(FetchData.java:323) at it.unimi.di.law.bubing.frontier.FetchingThread.run(FetchingThread.java:253)The VisitState is subsequently Killed.
When I look at the site using my browser, it doesn't seem to complain, though. A lot of sites are affected by this problem.
The text was updated successfully, but these errors were encountered: