What I did: I tweaked a Wordpress website so it will load within 2.3 seconds instead of the former 5 seconds. As a final step, I enabled HTTP/2 in the LAMP server (PHP7.0, Apache 2.4) and restarted Apache.
Issues: On doing this, the Time to First Byte jumped from 500ms to 9 seconds and the website PNG and JPEG images in the Speed Load Test (GTmetrix and Webpagetest.org) are now resulting in 404. Please, see screenshot here https://www.diigo.com/item/image/5pj5q/vt0g
Overall, the Speed Load Test is showing me that the website is loading at 20-30 seconds, instead of the former 2.3 seconds.
I am at a loss about how to solve those two issues caused by HTTP/2. Any advice is welcome.
I may have found the answer. It has to do with SSL Certs. At least for my situation. I use WHM/CPanel and the SSL certs get shared. HTTP2 detects that and sends a 421 error.
From Apache : https://httpd.apache.org/docs/2.4/mod/mod_http2.html
Multiple Hosts and Misdirected Requests
Many sites use the same TLS certificate for multiple virtual hosts.
The certificate either has a wildcard name, such as '*.example.org' or
carries several alternate names. Browsers using HTTP/2 will recognize
that and reuse an already opened connection for such hosts.
While this is great for performance, it comes at a price: such vhosts
need more care in their configuration. The problem is that you will
have multiple requests for multiple hosts on the same TLS connection.
And that makes renegotiation impossible, in face the HTTP/2 standard
forbids it.
So, if you have several virtual hosts using the same certificate and
want to use HTTP/2 for them, you need to make sure that all vhosts
have exactly the same SSL configuration. You need the same protocol,
ciphers and settings for client verification.
If you mix things, Apache httpd will detect it and return a special
response code, 421 Misdirected Request, to the client.
I disabled http2 and the 404/421 errors stopped.
Related
with TLS 1.3 already in place, and around 94% of the browsers compatible with 1.2 (https://caniuse.com/#feat=tls1-2)
with certificates wittily available or even free
with amp even requesting https
What is left for http?
does it have any sense to spend a minute on developing under port 80 aside of a redirect?
please, do not vote negatively, this is a open question to the community, trying to figure out any real use-case for the http protocol
Static content, or content that we don't care it to be "stealed" or "trafficked", don't need HTTPS and still could use HTTP.
For example, you might not need HTTPS for the jquery.js script resource (or for some static logo image), at least in some trusted corporate Intranet. And HTTP needs less resources (both on server and on client side) than HTTPS (because no encryption occurs).
Also, in some cases, both the HTTP server and the HTTP client (the browser) is on the same local secured network, or even both running on localhost (perhaps your Linux laptop without network connection). Then you don't need HTTPS.
And server side HTTP libraries (like libonion) are slightly more complex to use with HTTPS than with HTTP.
I am starting to look into HTTP/2, running tests on Windows 10/IIS 10. From what I understand HTTP/2 is enabled there by default for secure connections. Yet when I am browsing a local site from Chrome 67.0.3396.99 - HTTP/2 seems slower, issuing more requests.
HTTP connection:
HTTPS connection:
Any idea why this is happening?
Your screenshot shows 8 additional requests being loaded over HTTPS so you are not comparing like for like. Investigate what those are and you'll likely have your answer.
Additionally while the latest version of IIS uses HTTP/2 by default you are better adding the protocol column to the network tab to confirm if this is being used. That way you know whether you are comparing HTTP to HTTPS or HTTP to HTTP/2 (over HTTPS).
HTTP/2 is primarily faster over high latency connections so you may not notice much difference over low latency connections (e.g. if testing with localhost) but it shouldn't really be any slower because of this (except for perhaps a small additional initial connection SSL/TLS negotiation time for HTTPS).
If a client is requesting a domain that does not have a valid CA signed certificate and the server not intend on supporting HTTPS but does support HTTP for this domain, what is the best way to handle this in the web server. Note, the server does handle requests for SSL (HTTPS) on other domains so it is listening on 443.
Example where this would apply is for multi sub-domains where the sub-domains are dynamically created and thus making it extremely difficult to register CA signed certificates.
I've seen people try to respond with HTTP error codes but these seem moot as the client (browser) will first verify the certificate and will present the hard warning to the user before processing any HTTP. Therefore the client will only see the error code if they "proceed" past the cert warning.
Is there a canonical way of handling this scenario?
There is no canonical way for this scenario. Clients don't automatically downgrade to HTTP if HTTPS is broken and it would be a very bad idea to change clients in this regard - all what an attacker would need to do to attack HTTPS would be to infer with the HTTPS traffic to make a client downgrade to unprotected HTTP traffic.
Thus, you need to make sure that the client either does not try to attempt to access URL's which do not work properly (i.e. don't publish such URL's) or to make sure that you have a working certificate for these subdomains, i.e. adapt the processes for creation of subdomains so that they not only have an IP address but also a valid certificate (maybe use wildcard certificates).
Considering these websites don't have to work with SSL, the webserver should close all SSL connections for them in a proper way.
There is no canonical way for this, but RFC 5246 implicitly suggests to interrupt the handshake on the server side by using the user_cancel + close_notify alerts. How to achieve this is another question, it will be a configuration of the default SSL virtual host.
user_canceled
This handshake is being canceled for some reason unrelated to a
protocol failure. If the user cancels an operation after the
handshake is complete, just closing the connection by sending a
close_notify is more appropriate. This alert should be followed
by a close_notify. This message is generally a warning.
If you are dealing with subdomains, you probably can use a wildcard certificate for all of your subdomains.
Adding the CA certificate to your client will remove the warning (that's what companies do, no worry).
When hosting with Apache, for example, you can use VirtualDocumentRoot to add domains without editing your configuration. Have a look at the solution provided here : Virtual Hosting in SSL with VirtualDocumentRoot
As the title says,
I currently have a website with https on sensitive pages and cached http on the rest for speed.
I know HTTP2 is faster than HTTPS. What I don't know is whether HTTP2 is faster than regular un-encrypted HTTP?
Would I see performance improvements if I encrypted everything with SSL and enabled HTTP2, compared to using HTTP without encryption but with caching?
It completely depends on your site.
However, saying that, there is practically zero noticeable speed penalty for using HTTPS nowadays - unless you are on 20 year old hardware or serving huge content (e.g. you are a streaming site like Netflixs or YouTube). In fact even YouTube switched to HTTPS for practically all their users: https://youtube-eng.blogspot.ie/2016/08/youtubes-road-to-https.html?m=1
There is a small initial connection delay (typically 0.1 of a second) but after that there is practically no delay, and if on HTTP/2 then the gains that m will give to most sites will more than make up for tiny, unnoticeable, delay that HTTPS might add.
In fact, if you have some of your site on HTTPS already, then either you are using HTTPS resources on some of your site (e.g. common CSS that both HTTP and HTTPS pages use) and already experiencing this delay, as you need to connect over HTTPS to get those even when on HTTP, or you are making them available over both and making your HTTPS users download them again when they switch.
You can test the differences with a couple of sample sites on my blog here to give you some indication of differences: https://www.tunetheweb.com/blog/http-versus-https-versus-http2/ - which is a response to the https://www.httpvshttps.com website that I feel doesn't explain this as well as it should.
I am trying to solve an issue with uploads to our web infastructure.
When a user uploads media to our site, it is proxied (via our Web Proxy tier) to a Java backend with a limited number of threads. When a user has a slow connection or a large upload, this holds one of the Java threads open a long period of time, reducing overall capacity.
To mitigate this I'd like to implement an 'upload proxy' which will accept the entire HTTP POST data of the upload and only when it has received all of the data it will proxy that POST to the Java backend quickly, pushing the problem of the upload thread being held open to a HTTP proxy.
Initially I found Apache Traffic Server has a 'buffer_upload' plugin, but it seems a bit bleeding edge and has no support for regex in URLs, although it would solve most of my issues.
Does anyone know a proxy product that would be able to do what I am suggesting (aside from Apache Traffic Server)?
I see that Nginx has fairly detaild buffer settings for proxying, but it doesn't seem (from docs/explanations) to wait for the whole POST before opening a backend connection/thread. Do I have this right?
Cheers,
Tim
Actually, nginx always buffers requests before opening a connection to the backend. It is possible to turn off response buffering using proxy_buffering or setting an X-Accel-Buffering response header for per-response buffering control.