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
Related
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
I would like to know if it's possible to make G-WAN 100% compatible with HTTP/2 by using for example the solution nghttp2 (https://nghttp2.org)
Sorry for the late answer - for any reason Stackoverflow did not notify us this question and I have found it only because a more recent one was notified.
I have not looked at this library so I can't tell for sure if it can be used without modifications, but it could certainly be used as the basis of an event-based G-WAN protocol handler.
But, from a security point of view, there are severe issues with HTTP-2, and this is why we have not implemented it in G-WAN: HTTPS-2 lets different servers use the same TCP connection - even if they weren't listed in the original TLS certificate.
That may be handy for legit applications, but that's a problem for security: DOH (DNS over HTTP-2) prevents users from blocking (or even detecting) unwanted hosts at the traditionally used DNS requests level (the "hosts" file in various operating systems).
In facts, this new HTTP standard is defeating the purpose of SSL certificates, and defeating domain-name monitoring and blacklisting.
Is it purely a theoretical threat?
Google ads have been used in the past to inject malware designed to attack both the client and server sides.
I plan to code a mighty web server. But I am unsure: should I do it in HTTP/1.x, or HTTP/2? I really don't like doing it in both (I know HTTP/2 is backward compatible to HTTP/1.x, but if it's superior AND is going to be adopted by the majority then I will only do it in HTTP/2 without the backward compatibility aspect).
How is the future looking like for HTTP/2? Are there any hints from standard bodies to change HTTP/2 or undo their mistakes?
Is HTTP/2 really worth it?
Finally, how is the expected HTTP/2 adoption by web browsers?
I would say this question is too broad for stack overflow, but will attempt and answer anyway:
I plan to code a mighty web server. But I am unsure: should I do it in
HTTP/1.x, or HTTP/2? I really don't like doing it in both (I know
HTTP/2 is backward compatible to HTTP/1.x, but if it's superior AND is
going to be adopted by the majority then I will only do it in HTTP/2
without the backward compatibility aspect).
No offence, and will give you the benefit of the doubt here that you are not trolling, but writing a web server is a major undertaking and you'd need to have detailed knowledge of the HTTP protocol amongst other things and it appears you don't have that to be honest. So you'll need to do a few years reading on the subject first.
HTTP/2 is not backwards compatible to HTTP/1.1. You basically start in HTTP/1.1 and upgrade to HTTP/2 if you support it (at a simplistic level). So you need to support both. And will do for some time. Even though browser support is good (see below) there will be numerous devices that won't speak HTTP/2 for some time. Some devices (primarily bots admittedly) still only speak HTTP/1.0.
How is the future looking like for HTTP/2? Are there any hints from standard bodies to change HTTP/2 or undo their mistakes?
Way too broad for Stackoverflows format.
Is HTTP/2 really worth it?
Yes.
Finally, how is the expected HTTP/2 adoption by web browsers?
HTTP/2 adoption can be seen here: http://caniuse.com/#search=http2
How is the future looking like for HTTP/2? and Finally, how is the expected HTTP/2 adoption by web browsers?
The HTTP/2 standard has passed acceptance and is being implemented by all major server vendors. In fact, server support has advanced, all major server vendors support HTTP/2 in their current releases. You can track all known implementations of HTTP/2 here.
Are there any hints from standard bodies to change HTTP/2 or undo their mistakes?
There will not be an HTTP 2.x. The standards body has already made this clear (although I can't find a link that proves it). the next version will be HTTP/3.
Is HTTP/2 really worth it?
Yes. The benefits of HTTP/2 are too long to list here. This article discusses them in depth.
When developing a web server you will need to take account of both HTTP1.x and HTTP/2. At the moment we are transitioning to HTTP/2 but you should provide backward compatibility to HTTP/1.x.
I'd like to move my client's site entirely to HTTPS in order to allow HTTP2 to work, however I was wondering is it ok (in the eyes of search engines) to serve older traffic (of which there is a lot and which would otherwise suffer a perf hit) that do not support HTTP2?
Is this dangerous to do from an SEO point of view? and
could you do the detection with tools like WURFL?
I want to stay current and offer improved perf/security to those on newer browsers but don't want those on older browsers in developing countries to suffer.
For what is worth, I did some tests a few weeks ago and I got the impression that Google's spiders don't see HTTP/2 yet. But as #sbordet pointed out the upgrade to HTTP/2 is optional, so just be sure to have a site that also responds to HTTP/1.1. Here are a few thoughts more:
Google's algorithms will penalize slower sites, but it is unlikely that you will take a big performance hit from using HTTPS in your servers.
Using HTTPS can actually boost your SEO. Doesn't have anything to do with HTTP/2.
Popular browsers that don't support HTTP/2: Safari and IE. Safari doesn't support any TLS crypto-suite compatible with HTTP/2, AFAIK. But that won't cause problems as long as you list HTTP/2-compatible suites first in your TLS server hello: ECDHE-RSA-AES128-GCM-SHA256 and ECDHE-RSA-AES256-GCM-SHA384 are the ones I know of. Then you can list weaker suites.
You don't need to serve different content depending on whether you use HTTP/2 or HTTP/1.1, as your question title may hint (sorry if I misunderstood).
Also, just because you updated to HTTP/2, it does not mean that your server cannot serve HTTP/1.1 anymore.
You can easily update to HTTP/2, and retain HTTP/1.1 support for older devices or networks that do not support or do not allow HTTP/2 traffic.
Whether a client and a server can speak HTTP/2 is negotiated: only if the server detects that the client supports it, then it will use it, otherwise the server will fallback to HTTP/1.1. Therefore you don't risk to make your site unavailable for older browsers in developing countries.
Then again, HTTP/2 implementations may vary, but typically they have to be prepared to clients that don't speak HTTP/2, and use HTTP/1.1 for those (because otherwise they won't be able to serve content and it will appear that the service is down).
I am looking for tools that can be used for debugging web applications.I have narrowed my search to the following tools:
HTTPwatch.
Fiddler.
ieHTTPheader
liveHTTPheader.
It would be great if some of you having experience with these tools could discuss their pros and cons (features that you like or you think are missing in some of the tools but present in others).I am majorly confused between HTTPWatch and Fiddler, I would prefer Fiddler (being free) if it could fullfill all or most of HTTPWatch's features (however I am ready to pay for HTTPWatch if it's worth it).
P.S. - I know HTTPWatch and Fiddler are far more powerful than the other two tools (let me know if you disagree).
I am sure most of you would want more details as to what I would exactly like to do with these tools however I would like if you could compare these tools taking a broader perspective in mind comparing them as tools in general.
** Disclaimer: Posted by Simtec Limited **
Here's a list of the main advantages of HttpWatch (our product) and Fiddler. Of course we're biased, but we've tried to be objective:
HttpWatch Advantages
Shows requests that were read from
the browser cache without going onto network
Shows page level events, e.g. Render Start, DOM Load, etc
Handles SSL traffic without certificate warnings or requiring changes to trusted root CAs
Reduces 'observer effect' by not requiring HTTP proxy at network level
Groups requests by page
Fiddler Advantages
Works with almost any HTTP client not just Firefox and IE
Can intercept traffic from clients on non-Windows platforms, e.g. mobile devices
Requests can be intercepted and modified on the fly, e.g. change cookie value
Supports plugins to add extra functionality
Wireshark works at the network layer and of course gives you more information that the other tools you have mentioned here, however, if you want to debug web applications by breaking on requests/responses, modifying them and replaying - Fiddler is the tool for you!
Fiddler cannot however show TCP level information however and in such cases you will need Network Monitor or Wireshark.
If you specify what exactly you want to do with the 'debugger', one can suggest what's more appropriate for the job.
Fidler is good and simple to use. Wireshark is also worth considering since it gives a lot of extra information
You could also use Wireshark which allows you to analyze many protocols including TCP/IP.
A lab exercise from a University lecture on using Wireshark to analyze HTTP can be found here: Wireshark Lab: HTTP
take a look at HTTP Debugger Pro
It works with all browsers and custom software and doesn't change proxy settings.