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.
Related
I have a Blazor WASM Application that shall be hosted inside the Backend that is implemented using gRPC on ASP.NET with .NET 5.0. When I try to debug the WASM application and as soon as the debugging Browser starts I get this error:
fail: Microsoft.AspNetCore.Server.Kestrel[0]
HTTP/2 over TLS was not negotiated on an HTTP/2-only endpoint.
All development certificates are installed and trusted and the websocket connection is established using wss:// scheme. So from my point of view the TLS negotiation should succeed.
I already found out that I can workaround that to a certain point by changing the Kestrel endpoint settings to use Http1AndHttp2 the problem then becomes that the gRPC connection from the frontend to the backend fails because of the downgrade to Http/1.
So my question is: Is there any option to debug Blazot WASM when using an Http/2 server on the hosting site?
If this is not possible: Can I determine somehow that the gRPC endpoints get delivered using HTTP/2 and the debugging endpoints via HTTP/1.1?
Here are some tips for checking TLS negotiation limitation on Http/2:
TLS version 1.2 or later
Renegotiation disabled
Compression disabled
Minimum ephemeral key exchange sizes:
Elliptic curve Diffie-Hellman (ECDHE) [RFC4492]: 224 bits minimum
Finite field Diffie-Hellman (DHE) [TLS12]: 2048 bits minimum
Cipher suite not prohibited.
So the solution is quitq simple: I used the wrong package. When using Blazor with gRPC the Grpc.Client.Net.Web package must be used (as stated in this article: https://learn.microsoft.com/en-us/aspnet/core/grpc/browser?view=aspnetcore-6.0#configure-grpc-web-with-the-net-grpc-client).
Then you do not have to use HTTP/2 and everything works like a charm.
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.
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 website that was devloped using ASP.NET MVC and hosted in the IIS with source and working properly.
Today i have hosted the website in production environment in another location in the same server and configured the IIS. While accessing the HTTPS page i have faced the below problem.
"Error 101 (net::ERR_CONNECTION_RESET): The connection was reset. for SSL"
Is we need to configure the IIS anything special to resolve this ?
Thanks,
Velusamy
It could be related to your ISP. I wrote a quick blog post about it -
http://blog.agmon.com/2013/07/05/solving-error-101-neterr_connection_reset-the-connection-was-reset/
This happened to me as I was messing around with other settings in IIS. Somehow in my HTTPS bindings for the site, the self-signed security certificate was removed (when editing the binding, SSL Certificate was "Not Specified".
All I did was reselect the correct certificate and it fixed the problem. I would check that this hasn't happened to you first.
This may be the maxRequest .net issue. Try adding the following to the appSettings of your web.config file.
<add key="aspnet:MaxHttpCollectionKeys" value="9999" />
You can test https Connect via Web proxy
Install / execute Fiddler. ( https://www.telerik.com/fiddler )
Link to the problem page with the Internet browser.
If the corresponding connection is possible,
It is seen in the problem of the user's Internet browser and Server's "Cipher suite".
Server's Cipher Suites and SSL/TLS Version confirmation
https://www.ssllabs.com/ssltest/index.html
Client's(Internet browser) Cipher Suites and SSL/TLS Version confirmation
https://www.ssllabs.com/ssltest/viewMyClient.html
One or more "Cipher Suites" must be the same. .
check the SSL and TLS version you support.
If the same "Cipher Suites" does not exist
Take IIS Crypto 2.0 down.
https://www.nartac.com/Products/IISCrypto/Download/
After executing the program, press "Best Practices" button to set.
Please restart the test after rebooting.
http://dev.d-0-b.kr/22
Reference site. (Korean)