I've installed a .Net-based website on multiple virtual machines (Windows 2012 R2), using the same version of the same installer on both. Part of this installation includes generation of a self-signed ssl certificate. When accessing the two websites over https, one is indicating "secure connection failed" when using Firefox, however the other server/website works fine. Both load in IE fine.
When looking at the page properties (from IE), the failing site indicates a connection of "TLS 1.0, AES with 128 bit encryption (High); RSA with 2048 bit exchange", while the successful one indicates "TLS 1.2, AES with 256 bit encryption (High); ECDH_P256 with 256 bit exchange".
What server settings should I be looking at to determine the difference between the two?
I tracked this down to an incompatibility between the self-signed certificate, which was using SHA512, and TLS. Changing the certificate to use SHA256 resolved the issue. The reason for the failure on one VM vs another was a registry setting, which dictated whether or not to support SHA512. The succeeding machine supported 512, the failing one did not.
https://blogs.technet.microsoft.com/silvana/2014/03/14/schannel-errors-on-scom-agent/
Related
I'm a novice in regards to Transport Layer Security stuff, to bear with me...
I have some https web apps that I test locally using self-signed certs created with selfssl.exe. The company recently pushed new rules to everyone's machines that prevent the browsers from loading https sites that use anything other than TLS 1.2. However, my browsers give me certificate errors when I load my locally-hosted test stuff if TLS 1.0 is not enabled. Is it possible to generate self-signed certs that will work with my browsers if only TLS 1.2 is enabled?
I'm using Windows 7 64 bit with IIS 7.5, and I test with a variety of browsers (IE 11, Firefox 46, and Chrome 50).
No, it is not possible
SSL/TLS in all versions works with x509 digital certificates. The difference between TLS versions is the protocol rules, not the certificate.
The browser warns usually when the used protocol is old(consideres less secure) or the certificate is not trusted
Eventually figured this out. The answer is kinda dumb...
On Windows 7 / Windows Server 2008 R2, the TLS 1.2 protocol is installed, but disabled by default. When Big Brother pushed everybody to TLS 1.2, they did it with SCHANNEL registry entries, but they did not create the "DisabledByDefault" entry set to "0" so it blew up the security of all the Windows 7 users on the domain.
So, if you're going to use registry hacks to push users over to TLS 1.2, be sure to follow the instructions from Microsoft and remember to create a "DisabledByDefault" entry in the TLS 1.2 SCHANNEL key. :-)
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn786418(v=ws.11)
I'm working with Delphi and using Indy components for SSL connection. I had Fiddler2 running and was able to see SSL traffic, but had to upgrade Indy to newer version because it had some errors. For compatibility between Indy and OpenSSL I also upgraded to OpenSSL1.0.2a. After this upgrade it seems that it has switched to SSL3.3 a newer protocol than what was used before. I installed Fiddler4.5, .NET framework 4.5 and enabled TLS1.2 as descriped on http://blogs.telerik.com/fiddler/posts/13-02-11/fiddler-and-modern-tls-versions. I also reimported Fiddler's certificate to my trusted root certificates, however i can still not decrypt the SSL traffic.
Following is written in Fiddler:
This is a CONNECT tunnel, through which encrypted HTTPS traffic flows.
Fiddler's HTTPS Decryption feature is enabled, but this specific tunnel was configured not to be decrypted. Session Flag 'X-No-Decrypt' was set to: 'PeekYieldedUnknownProtocol'.
A SSLv3-compatible ServerHello handshake was found. Fiddler extracted the parameters below.
Version: 3.3 (TLS/1.2)
I tried to search Indy and OpenSSL source for the string "X-No-Decrypt", but it does not seem to be included anywhere. Accoring to fiddlers documentation it seems to be a string that you can include if you dont want fiddler to decrypt this particular session, but i have no idea where this string is included from.
Any suggestions?
Thanks /Rune
The text PeekYieldedUnknownProtocol indicates that when Fiddler looked at the first bytes sent by the client within the CONNECT tunnel, those bytes were not those of a HTTPS handshake. To avoid breaking whatever type of traffic is flowing through the tunnel, Fiddler simply passes the bytes back and forth without interpreting them.
To debug this further, your best bet would be to contact me using Help > Send Feedback in Fiddler. If you can send me a SAZ File (File > Save Session Archive) containing the traffic, I can investigate this problem further.
If you can't share a SAZ file, please at least right-click on the CONNECT in the Web Sessions list and choose Properties. Update your question with the value of the x-CONNECT-Peek flag.
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.
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).