I have successfully built the Web Application but when I try to view the app in the browser it throws "Could not create SSL/TLS secure channel". I tried changing the compile to Debug mode and then it throws "The client and server cannot communicate, because they do not possess a common algorithm" errors.
I have also checked the Regedit.exe for the SSL Protocols and eveything is enabled. I also have the client side test certificate in installed on my machine.
My concern is does the Web Application have the ability to pick the installed certificate from the App Pool or should I write any specific code to use the that particular certificate?
I'm not familiar with .NET, but this kind of error typically occurs if the server is not configured to use a certificate. In this case the only ciphers it can offer are ADH etc, i.e. ciphers which don't require a certificate. Because in this case the connection would be vulnerable to man-in-the-middle attacks most clients don't support such ciphers by default and thus you get the error message that client and server have no ciphers in common.
Related
Is it possible to use Kafka with SSL encryption but with no server verification nor client authentication?
I know that by default the latter is disabled, but is it possible to also disable the former?
I encountered the similar problem. Since kafka is a java process, it will load the default jdk certs when running, which is under /usr/local/jdk/jre/lib/security/cacerts. if your server is trusted there, (in my scenario, my kakfa server is MSK, and is trusted already), then you don't have to config all the keys and certs.
So all in all, I only added kafka config of security.protocol=SSL and it worked.
I want to enable SSL keys renegotiation in Tomcat as described in https://www.rfc-editor.org/rfc/rfc5746. Tomcat will use JSSE implementation for SSL. Which cipher suite should I use to enable the same?
Tomcat Version: 6.0.44
Java version: Java 1.8
Protocol - TLS 1.2
Meta: I'm not sure this is ontopic here, but security is on-hold. Migrate if necessary.
All Java 8 and 7, and 6 from 6u22 up, enable secure renegotiation per 5746. See the documentation. By default, it is used if the peer offers or accepts it; if the peer does not, the connection is still made but renegotiation is not done because it would/could be insecure. This can be varied two ways:
set system property sun.security.ssl.allowLegacyHelloMessages false. JSSE will not make the connection if the peer does not agree to 5746. This is not actually more secure, but it is more visibly secure to simple minded basic scanners, and people who care about simple minded basic scanners like auditors
set system property sun.security.ssl.allowUnsafeRenegotiation true. This is less secure if the application depends on peer credentials checked after a message. Since client always checks server before any data, this means if server requests (not requires) client authentication, and checks auth status after a request, it can wrongly accept a forged-prefix request.
The protocol implementation of 5746 sometimes uses a fake "ciphersuite" (officially SCSV -- Signalling Cipher Suite Value) in ClientHello. JSSE client can be configured using the "ciphersuite" name TLS_EMPTY_RENEGOTIATION_INFO_SCSV whether to use this SCSV or the extension. All servers always use the extension, and thus this configuration has no effect on JSSE server.
I have a C++ application that has a SSL/TLS communication with its own server and i don't have any access to that server. I'm trying to find out what is it sending from my PC to the server.
I tried burp and fiddler as man-in-middle but it didn't work. The application does not support Proxy so i tried routing the traffic using proxifier to burp and fiddler but it didn't work.
So I came up with these articles https://isc.sans.edu/forums/diary/Psst+Your+Browser+Knows+All+Your+Secrets+/16415 and http://ask.wireshark.org/questions/4229/follow-ssl-stream-using-master-key-and-session-id
I just need to know , How I can find Master-key and Session-ID to decrypt SSL/TLS trafic.
It depends on the TLS cipher suite being used. If the ciphersuite uses forward secrecy (DHE) you cannot decrypt the stream. If it uses RSA encryption then you need at least the private key of the server. If it also uses client authentication then you would also need the private key of the client. if it uses symmetric encryption you need the symmetric (master) key from either one of them.
But if you do have a C++ application, I would simply add logging to that application (at the lowest level).
You can use following alrternates on a x86 windows
STRACE - http://blogs.msdn.com/b/emmanubo/archive/2007/06/04/introduction-to-strace-httpreplay-support-tools.aspx
SOCKTRC if this app is on windows checkout
http://blogs.msdn.com/b/emmanubo/archive/2007/08/03/socktrc-tool.aspx
HTTPREPLAY -
generally used for browsers but here can be used to view the responses in the UI
I am having the same issue with client certificates that many people have reported, but none of the solutions I've seen have worked for me. I have a client I wrote in VB.Net (using VS 2010 and .Net framework 4.0) that needs to connect to a web service running on Apache Tomcat/5.0.27. It works fine with SSL when client certificates are not required, but as soon as client certificates are required, it fails with “THE REQUEST WAS ABORTED: COULD NOT CREATE SSL/TLS SECURE CHANNEL”
Testing it with Internet Explorer (8, 9 and 10, on XP and Win7x32), when SSL is enabled (configured on Tomcat by setting sslProtocol="TLS" secure="true" scheme="https" in the system.xml file), but client certificates are disabled (clientAuth="false"), IE is happy after the CA certificate and the server certificate are installed on the client PC. (IE will complain without the certificates, but you can tell it to ignore the warning. When the certificates are installed, it connects without any warnings.) When client certificates are required (clientAuth="true"), IE will not connect. After I import the client certificate file, it still does not connect. IE shows that the client file is installed, and it shows the certificate is ok and it trusts the CA, but it shows it in what seems to be the wrong store: Intermediate Certificate Authorities, and client authentication is not ticked under Purpose. The MMC certificates snap-in shows the client certificate is in the Personal - Current User store.
The certificate was issued to us by the owners of the web service, so in theory it has to work. The properties look ok, and the purpose shows "All application policies".
I need to get this to work with my .Net client. I use a Web Reference to create the connection to the web service. I set PreaAuthenticate=True, and attach the certificate file to the web reference, and can see it attached in the IDE. Using Network Monitor, I can see that the server sends certificates to the client (in two large packets), but the client doesn't seem to send any back to the server.
I have tried various recommendations, e.g. setting ServicePointManager.Expect100Continue = true and
ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3, but this makes no difference.
I have disabled firewalls and proxy servers, so nothing should be blocking the traffic.
I'd appreciate any help.
Ok, it turns out there is a problem with the certificate they supplied, or it is somehow incompatible with the client. I found instructions on using OpenSsl to create a certificate, and it works with their server. They used java's keytool to make the certificate, so either it creates an incompatible certificate, or they didn't use the right procedure, and the procedure I used with OpenSsl is the correct one.
The steps in OpenSsl are to create a private key file (client.key), create a certificate request (client.req), sign the key (client.pem) then export it (client.pfx).
Scenario: calling a client web service over SSL (https) with mutual SSL authentication. Different service endpoint URLs and certs (both keystore and truststore) for test vs. production environments. Both test and production environments run tomcat / JBoss clustered. Production environment has load balancing / BigIP, runs Blade and non-Blade machines.
Truststore is set (using -Djavax.net.ssl.trustStore=value) at startup. Keystore is set using System.setProperty("javax.net.ssl.keyStore", "value") in Java code. Web service call made using Axis2. All works fine in test environment, but when we moved to production environment (6 servers), it appears certs are not being forwarded for the handshake. Here's what we've done:
in test environment, handshake using test versions of certs has been working all along, with no ssl debugging enabled
confirmed in test environment that handshake with client production
endpoint succeeds (production certs,
both ours and theirs, are fine) --
this was done using
-Djavax.net.debug=handshake,ssl
confirmed that the error condition occurs on all 6 production servers
took one server out of the cluster, turned on ssl debugging for
just that one (with a restart), hit
it directly, handshake works!
switched to a different server without the debugging turned on,
handshake error condition occurs
turned debugging on on that second server (with a restart), hit it directly, handshake works!
From the evidence, it seems like somehow the debugging being enabled causes the certificates to be properly retrieved/conveyed, although that makes no sense! I wonder whether somehow the enabled debugging makes the system pay attention to the System.setProperty call, and ignore it otherwise. However, in local and test environments, handshake worked without debugging enabled.
Do I maybe need to be setting keystore on server startup like I'm setting truststore? Have been avoiding that because the keystore will differ for each of our test environments (16 of them).
Turns out that the debug setting was a red herring. What actually bit us was that there was an existing client with an SSL/basic authentication web service we call when one of their users logs in. Since in that context the keystore wasn't relevant, the javax.net.ssl.keyStore property doesn't get set -- but the SSL exchange still tries to load a keyStore (which ends up not loading any certs). Since, unfortunately, even if the javax.net.ssl.keyStore value is changed, it does not get reloaded, calls to the other client's web service sent along no keystore certs.
The solution was to set the keyStore property at server startup rather than at the point of the web service call. If at some point in the future we need to be able to use different keyStores in different contexts, it looks like we'd need to implement a custom SocketFactory.