First I disable the following things in windows server 2016.
Triple DES cipher
RC4 cipher
TLS CBC Mode ciphers
TLS 1.0
TLS 1.1
Then, I reboot the server.
Finally, I call the web application which is hosted at above server from my client browser.
Here is the problem I can not connect to that web application via browser
What am I missing something?
What should I do to be able to use from end users?
Thank you.
Just turn off the windows server firewall to be able to connection from client site.
It works for me. It's not affected due to disability of above ciphers and tls.
Related
I have deployed a web application on IIS 10 and it was running till yesterday but now it is giving error with IE as.
Turn on TLS 1.0, TLS 1.1, and TLS 1.2 in Advanced settings and try connecting to again. If this error persists, it is possible that this site uses an unsupported protocol or cipher suite such as RC4 (link for the details), which is not considered secure. Please contact your site administrator
Please suggest any solution.
My telegram Bot doesn't receive updates anymore, Because of the last api update Which only works with tls 1.2 .
I tried with wireshark listening to check , I found that the outgoing requests are sent over tls1.2 successfully But the INCOMING ONES (updates,commands sent to my bot) fail due to HANDSHAKE FAILURE.
Transport Layer Security
TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Handshake Failure)
Content Type: Alert (21)
Version: TLS 1.2 (0x0303)
Length: 2
Alert Message
Level: Fatal (2)
Description: Handshake Failure (40)
Knowing that i tried :
Enabling Tls 1.2 using Internet Options
Added client and Server Keys to SChanel entry in registry
(DisabledByDefault = 0 ; Enabled = 1)
Installed This Update kb3140245
Installed all the important updates on my windows server 2012
What should i do to solve this issue ?
Thanks for your time.
Note: This is an edited repost of my original answer, as it was deleted for being low-quality.
The issue is that in the TLS1.2 set of cipher suites, the Telegram API only accepts a limited set. Of those only TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) and TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) are supported on Windows 2012. A secure channel for SSL / TLS could not be created on create new TelegramBotClient
However Microsoft has disabled their implementations of those ciphers on Windows 2012 already in 2014 as part of a remote code execution patch: MS14-066: Vulnerability in SChannel could allow remote code execution: November 11, 2014
They are considered unsafe ciphers by among others Qualys SSL Labs and NARTAC.
Note that the Telegram API supports many other, more secure ciphers even TLS 1.3, but none of those are supported by any version of Windows 2012. TLS 1.3 is not supported by any Windows version at the time of writing.
In summary, this explains why the problem occurs. The bad news is that there is no good solution on Windows Server 2012. The oldest Windows Server version that supports Telegram bots currently is Windows Server 2016. I'm moving my bot to a Ubuntu 19.10 server.
we are running a Dotnet Core 3.0 application that provides a web api via Kestrel. By default Kestrel has set available protocols to Protocols.Http1AndHttp2.
On one of our testmachines it turned out that http/2 does not work in combination with Google Chrome (77.0.3865.90). The browser displays an error with ERR_HTTP2_INADEQUATE_TRANSPORT_SECURITY message. The fallback to http1 does not work in this case because the browser does support http/2 in general.
Microsoft Edge btw. does support requesting the same endpoint via http/2.
I tested the certificate on my develop machine and it turns out that this works as expected. So it does not seem to be a problem with the certificate itself rather than the server hosting the application. My local machine is running Windows 10 Pro (1903). The server is running Windows Server 2012 R2 Datacenter (6.3.9600).
The application will be hosted at our customers servers as a self contained package and we will not have an impact on what servers the api will be running.
Instead of disabling http/2 completely, we would like to check if all browsers will accept the provided certificate in combination of http/2. I'm not sure how to find this out on server side. To us it seems to be some kind of problem regarding to the provided cipher suites but I got no idea on how to check the compatibility on server side.
Does anyone have an idea on how to check the compatibility?
It’s not the certificate it’s the cipher suites.
Run your site through this tool: https://www.ssllabs.com/ssltest/ (or download and use https://testssl.sh if not publicly available, internal site) and you’ll see the cipher suites configured.
HTTP/2 blacklists older ciphers and Chrome won’t use HTTP/2 if those are configured. The list is here: https://www.rfc-editor.org/rfc/rfc7540#appendix-A but basically you probably should be using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for Chrome.
This post tells you how to change them for IIS: https://medium.com/#rootsecdev/configuring-secure-cipher-suites-in-windows-server-2019-iis-7d1ff1ffe5ea
I have a VB.NET 4.5 application on Windows Server 2008 R2 that must connect to one of our other internal applications on a Tomcat server via TLSv1.2. According to our security scans and server config (in preparation for PCI), we can only use these ciphers on that server:
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
I have generated the service class from the WSDL as usual, but a Wireshark capture doesn't list any of these ciphers as an option.
My questions:
What library does Microsoft.NET use behind the scenes for TLS connections? For example, does it still use SChannel?
Is there a way for me to enable / install new ciphers for VB.NET to use?
If it's using SChannel, maybe I can do some registry changes to get it working...? Or is it possible that these ciphers are just not available on Windows Server 2008 R2?
Thanks in advance!
.NET supports them but by default .NET TLS implementation is using only SSLv3/TLSv1 and it doesn't offer those ciphers.
To enable TLSv1.1 and TLSv1.2 (not sure which one actually enabled those ciphers) use:
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;
This will enable TLSv1.1+ (and in process disables SSLv3) and .NET should start offering TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.
Cheers
The environment setup has an ASP.NET webservice on IIS 6 connecting to a SQL Server over the network.
I am trying to understand, whether it's possible to secure the calls between IIS and SQL Server 2008. Is it possible? Is it something on the lines of SSL?
thanks for reading!
If you still want to after Pierreten's answer...
Yes, you can enable SSL Encryption for all SQL Server connections.
SQL Server SSL Encryption, server side, is described here. And in KB 316898 too
"Server side" requires only a server certificate and all connections are encrypted
"client side" requires client certs and is optional, and only for that client
Certain client libraries (notably MS JDBC) do not support server side s you may invalidate your host's monitoring (This has happened to me a time or 2)
a blog entry too
Assuming your SQL box is on the same network as your iis box hosting the service, and both are tucked away behind a firewall, there's no need for that extra security
If both machines are in the same domain, an efficient and easy to manage way to secure the link is by using IPsec.