I inherited a web app that acts as a corporate dashboard. It's an ASP.NET app. .NET version = 4.7.2
It's running on two Windows 2016 Standard servers running IIS 10. Been in operation for many years.
One of the things the app does is make an HTTP request to a particular https:// URL, grab the data, parse out the JSON, and cache the list of objects. This has been working for many, many months. (Note: the "remote" server we're calling is still "in-house". Another person within my team basically "owns" that.)
Well, on Thanksgiving Weekend, it looks like the Prod App Pool cycled. And immediately that query started erroring with "System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel."
Myself and a few other folks were paged. At the time, we didn't notice (in Event Viewer) that the App Pool had cycled. After a few hours of investigating (and rebooting the app servers), the fellow who "owns" the server we are querying quickly set up a new end point for that same resource...setting it to allow HTTP connections / not require the use of HTTPS. The intention was that this would be a work-around until we could investigate the problem later.
Well, it's now "later".
The remote server that we are calling appears to require the use of TLS 1.3. I confirmed this by using both Firefox and Chrome on my own laptop to pull up a couple of https: urls on that server.
So, Ah-ha, I thought to myself, I had found information earlier this afternoon suggesting that Windows Server 2016 Standard didn't support the use of TLS 1.3! (https://learn.microsoft.com/en-us/windows/win32/secauthn/protocols-in-tls-ssl--schannel-ssp-#tls-protocol-version-support)
But then I remembered: Earlier, I had been able to pull up those https: URLs in Chrome while logged onto my app's webservers! Sure enough, I went over there and retested with Firefox and Chrome. Both said the connections they'd made were using TLS version 1.3 !!
So, what the ???? That makes it seem like Windows Server 2016 Standard DOES support TLS 1.3 !??
And, from everything I've read, since my app is using .NET version 4.7.2, it should default to using whatever the default protocol for the OS is. So, shouldn't it too be using TLS 1.3 ? Why the heck can't it make a connection?
I'm certainly needing some direction on what to do next.
Thanks!
Background
Many statements from your question body above are true, but you need to put the contents into contexts so as to get the whole picture.
First, Chrome/Firefox supports TLS 1.3, but that support comes from the crypto libraries (many options out there, Mozilla NSS, OpenSSL and so on) they ship with themselves, not from Windows native crypto API.
Second, like you found out, Windows Server 2016 does not support TLS 1.3 natively because its underlying crypto API lacks of TLS 1.3 support. TLS 1.3 support is only included in Windows Server 2022 at this moment (and whether it will be back ported to previous Windows versions is unknown).
Third, when you try to analyze Windows components (like .NET Framework) or products, you need to identify what they rely on to perform TLS, Windows native crypto API or their own dependencies (like Chrome/Firefox does).
Answer to your specific ASP.NET question
Sadly it is well known that BCL classes in .NET Framework rely on Windows native crypto API, so on Windows Server 2016 you can go with TLS 1.2 at most.
If your application needs TLS 1.3 badly, you need to upgrade to Windows Server 2022, or switch to a third party crypto API.
Reference
https://www.quora.com/How-does-one-decide-between-OpenSSL-GnuTLS-and-Mozillas-NSS
TLS 1.2 on Windows Server 2003 and XP
Related
How should I access a serial port on a client PC from a webpage in a production environment?
Ideally coded in C# and client Blazor, but any suggestions very welcome.
Any example applications on the web?
Web Serial API and Javascript option works in Chrome if you enable the experimental option: "Experimental Web Platform features" : Enables experimental Web Platform features that are in development. – Mac, Windows, Linux, Chrome OS, Android. #enable-experimental-web-platform-features
https://bugs.chromium.org/p/chromium/issues/detail?id=884928
Being experimental precludes use in a production environment till it is formally released (experimental licence must be renewed every 6 weeks, expires in September 2020 and the functionality can be removed by Google at any time.)
So far the only solution I can think of is to create an ASP.NET Core Service application that must be installed on the client and the webpage application must connect to this local API to use the local serial port.
Any technical issues that would prevent this service approach from working? Other approaches I should consider.
The web application will be designed to interface with a central/upper arm blood pressure monitor that outputs large XML (or JSON) results after each measurement. The measurements will be saved into a "cloud" service for research and patient monitoring.
Thank you in advance for suggestions and comments.
We got vulnerabilities on windows server 2008R2, we are using BizTalk server 2010, they are going to disable RC4 ciphers, However how do we check what are all the ciphers our BizTalk server supporting and where do we find those list.
Basically they are going to be disabling TLS 1.0.
What you need to do is install the .NET Framework v4.5.2, as the actually ciphers you are talking about are at the .Net layer rather than in BizTalk.
Then you need to set the registry keys to disable TLS 1.0 and enable it defaulting to a stronger cryptography.
There is a good article about "BizTalk Server 2010 and support for TLS 1.2"
Well, hold on. They are only 'vulnerabilities' if you're actually using them.
If you have no TLS(SSL) 1.0 endpoints (Receive Locations), you don't have a problem.
If you are calling TLS(SSL) 1.0 endpoints (Send Ports), then your trading partner needs to update first, then you can move to TLS >1.0.
I'm trying to learn about WebSocket as I see many possibilities with it and would like to explore it, but I am having a hard time understanding the basic requirements for it.
There exist a ton of blogs out there praising WebSocket like was it God and they explain how to develop WebSocket applications brilliantly.
However I don't understand when they all shortly mention that you need a WebSocket compatible server and then none of them tells you how to set it up and what you need to do to make it work properly when you call it through your client side scripts etc. - Even WebSocket.org fails to explain it.
Can anyone point me in the right direction?
Say I have an ASP.NET website and would like to use WebSocket to push notifications, maybe even have a chatroom. What would I need to do to make my Javascript-based chatroom application working?
If you are using ASP.NET, you will need IIS8 to work with WebSockets integrated in the app (so you would need Windows 8 or Windows 2012). Or, you can have a WebSocket server in another port/server.
If your "push" requirements are not very exigent, you can try SignalR: http://www.asp.net/signalr. Check out their tutorials to get started. But again, you won't be able of using WebSockets unless you are using IIS8.
Other WebSocket frameworks are XSocket.NET and SuperWebSocket. Or if you want you can take a look at my WebSocketListener that I am developing, that is just a lightweight WebSocket connector and nothing more, although it is under heavy development at the moment.
From client side, the WebSocket API is the same for all browsers.
Your question is very broad and not any particular problem specific.
WS (WebSockets) is protocol that is implemented in most modern browsers and platforms, and is well consistent.
But same way as you need something to be as HTTP web server (ASP.Net + IIS, Apache + PHP, node.js, python, etc) you need similar or compatible technology for WebSockets. As it is different protocol, your technology have to support. From "recognising" traffic as WS, directing to right process via socket/proxying, handshaking, deserializing traffic into actual data, and providing you an interface to work with all of it.
So you need basically google: "%YOUR TECH/LANGUAGE% WebSockets". That will give you information on how to use WS on your platform.
You need to understand specifics that it is different protocol, so it might not be that "friendly" with some complicated infrastructure cases.
ASP.Net 4.5 do support WebSockets by default, just find documentation on how to use it in ASP.Net.
And this question would not be raised if you would try to do some experimentation and prototyping with WebSockets in first place.
How many Concurrent requests are allowed in asp.net development server? I am using asp.net 4.0
What is your OS? Not exactly specific to Dev server:
Windows 8 / IIS 8 Concurrent Requests Limit
references this from IIS.net site, a bit old but again, describes limits based on OS
Server OSes don't have preset limits....
i got the answer...it depends upon browser...see this line "IE7 allowed only two concurrent connections per host. But most browsers today allow more than that. IE8 allows 6 concurrent connections, Chrome allows 6, and Firefox allows 8"...and these links :- link1 and link2...thanks 4 the help...i ll going to use sharding as explained in this link3
I have been studying the Upgrade header field in HTTP 1.1 (RFC 2817) and happened to read the wikipedia entry for HTTP. That article has the following statement:
"Browser support for the Upgrade header is, however, nearly non-existent, so HTTPS is still the dominant method of establishing a secure HTTP connection."
I was hoping to implement my web service so that it relied on the Upgrade header field in order to avoid having to listen on two sockets (one for HTTP and the other for HTTPS). This statement, which I have not been able to verify any other place, makes me somewhat nervous about doing so. Is the above statement in wikipedia anywhere near correct or is it a gross generalisation?
I was researching this for that Wikipedia page actually and came across this question. I've looked around and here's the browser support situation as near as I can tell:
Chromium supports the Upgrade header as indicated by, for instance, this bug.
Firefox does not support "Upgrade: TLS" despite an open bug from 2005, last comment from 2010. My guess is they won't be adding it anytime soon.
Internet Explorer 10+ probably does, given this article that describes using Upgrade to connect to a websocket server. This commit message also implies IE 10 supports "Upgrade: websocket".
Safari 6+ supports Upgrade (see here).
For all of the supported browsers, I only found examples of "Upgrade: websocket" usage, none saying that upgrades to TLS would work. So the overall answer is that it's risky to rely on this in a production application.
Server support seems better; Apache has had "Upgrade: TLS" support since 2.1.
I would rather like to have it all in http, but the current situation leans more to Server Name Indication, as its widely supported. Its also hard to indicate that you want the client to upgrade using the url. So, if the goal is virtual hosting, one way to do this is TLS "server name indication". See RFC 3546 http://www.ietf.org/rfc/rfc3546.txt or http://en.wikipedia.org/wiki/Server_Name_Indication