My websites are https and my hosting company says my server is http2 enabled and functioning correctly. However, when I check my sites they are always utilizing the http1.1 protocol. I have contacted tech support and they say http2 is working and even sent me a screen shot to prove it.
I have tested both of my computers via my home internet and my mobile hotspot on both Firefox and Chrome. I have also tested with my ESET antivirus disabled. It always shows http1.1 via the Network Tab Protocol Column. I also have some site testing tools tell me http2 is function and others say that http2 isn't functioning.
I am looking for a cause-solution and my hosting provider is giving me nothing to work with. They almost act as if they have something to hide.
I am on a shared hosting plan. Apache Version 2.4.33. Anyone have any thoughts?
Additional Details:
I checked 3 http/2 site checking tools and all 3 said my server/website supports http/2. In addition to Chrome and Firefox Network tabs showing http/1.1, Chrome lighthouse(via DevTools > Audits Tab) says my site is not utilizing http/2.
Via Hosting Tech Support:
There is no load balancer, prefork MPM, and nothing in front of server.
Via https://www.ssllabs.com/ssltest
ALPN = Yes (h2 http/1.1)
Cipher = This server accepts RC4 cipher, but only with older protocols
Site URL:
https://spinerealignment.com
Related
I have a setup which involves devices connecting to a server via web sockets. I'm experiencing a strange problem where they can connect to one test server without issues, but cannot connect to a different server (hosted on Azure).
I've installed Wireshark on both of them, and can watch both the successful connection and the unsuccessful connection. It appears that the unsuccessful one attempts to initiate an SSL handshake.
Here is the successful connection:
Here is the unsuccessful connection:
It seems like the client in the successful connection is simply setting up an HTTP web socket, but in the unsuccessful setup it's try to set up a secure connection.
Why would the client be setting up different connections depending upon the server address?
The client code to create the websocket is just javascript, invoking new Websocket(address), and in both cases the address begins with the 'ws' prefix.
I have done some further investigation and found another weird behavior. As it happens, there are two domain names pointing to the same server.
If I used the domain name with the top level domain "com" (XXXX.australiaeast.cloudapp.azure.com), then the connection works.
If I used the domain name with the top level domain "dev" (comutername.mydomainname.dev) then the connection fails, with the weird TLSV1 packet.
Both works fine if I run the same client code on the Microsoft Edge browser.
This appears to be a defect in Chrome's implementation of The WebScoket API
I have posted a defect here, let's see how it goes. https://bugs.chromium.org/p/chromium/issues/detail?id=1067076
The issue in play here is HTTP Strict Transport Security (HSTS)
A browser can be configured so that certain domains have an HSTS policy attached, meaning any insecure link will automatically be converted to a secure link.
This policy will be applied if a request returns a Strict-Transport-Security header. But, and here's the significant bit, the Chrome and Firefox browsers automatically apply the policy to all dev domains.
It appears that up until recently, the Chrome browser and Chrome OS was not observing the policy with regard to WebSocket connections. This has changed, and now WebSockets will observe the HSTS policy.
The upshot is, if you have a websocket using the ws protocol and not the wss protocol, and it's on a .dev domain, your Chrome and Firefox browser will not be able to connect to it.
I have a site, that runs on a Nginx 1.10.0 on Ubuntu 16.04 server (OpenSSL 1.0.2h). I want to serve this site over HTTP/2, so I configured Nginx accordingly:
listen 443 ssl http2 default_server;
listen [::]:443 ssl http2 default_server
And it works fine in FF 47 and Chrome 51 on my office Ubuntu 15.10 desktop and in the same browsers on my home Ubuntu 15.10 desktop.
However on my home Windows 10 desktop and laptop HTTP/2 works only in FF. Chrome 51, IE 11 and Edge are using HTTP/1.1 on this site.
So, I'm baffled. This service says, that my site supports HTTP/2 and ALPN (which is required for HTTP/2 to work in Chrome since version 51).
Chrome versions and capabilities are exactly the same:
HTTPS works, and Security panel in Chrome Dev Tools shows, that everything is secured.
This demo in Chrome, IE and Edge displays message "This browser is not HTTP/2 enabled.", and "Your browser supports HTTP/2!" in FF.
But HTTP/2 on medium.com works just fine in all of this browsers.
So, my question is: what's going on and how to fix this?
Are you using antivirus software (e.g. Avast) and is it inspecting your HTTPS traffic?
It does this by acting like a MITM so you connect it it and it connects to the real website. And if they only support http/1 (which as far as I know they only do) then that would explain this. Though oddly not for for Medium unless you have an exception for this.
Should be easy enough to check by looking at the HTTPS cert when visiting the site to see if it was "issued" by your local Avast server.
If not that then suggest you look at your ciphers as HTTP/2 is picky about which ones it uses. Anything weird showing on https://www.ssllabs.com/servertest for your site? What cipher is it using for Chrome?
I have an old VB app that uses the Microsoft Internet Transfer Control (or Inet) to read info from a web page over HTTPS. It is installed on a number of Windows 10 machines and it works fine on all of them except for one. On this machine, when the call is made over HTTPS, the response comes back blank. The request never makes it to the web server because there is no entry for it in the IIS logs. Calls over HTTP to the same URL work just fine, only the HTTPS call has this problem.
I suspect the problem is with TLS 1.0. That protocol is disabled on the web server. I'm aware that older browsers, including old versions of IE, require TLS 1.0. Is there a setting that controls whether Inet can support TLS 1.1+? I did check Internet Options and "Use TLS 1.1" and "Use TLS 1.2" are already checked, so maybe these settings don't apply to Inet and I need to look elsewhere. Or is the problem something else?
Here is the code that uses Inet to make the HTTPS call. It's pretty straightforward.
response = Inet1.OpenURL("https://my_site/some_page")
' response is blank
I had the same issue. Experimenting with internet properties I found that unchecking "Use HTTP 1.1", leave "HTTP 1.1 through proxy connections" checked, fixes the problem. Have to close your program and restart it if you make the change while it's running. Don't have to reboot your PC. Hope this helps
if you disabled the TLS 1.0 in the WebServer then it will not work in the machines those are supported till TLS 1.0.
VB browser uses IE7 by default. If the HTTPS link works on the machine regular browser then you need to check for document mode settings otherwise you need to enable TLS 1.0 in the webserver.
We've recently moved to HTTPS for all requests to our public website and application. We're seeing issues with clients that apparently have TLS 1, 1.1 and/or 1.2 disabled in Internet Explorer (and/or other browsers), the net result being they can no longer access our domain 'at all'.
Our certificate set up uses TLS 1.2 and I'm forcing HTTP requests in .htaccess to HTTPS. What's the accepted best practice to negate issues with misconfigured browsers? Allow access over HTTP? Allow access but display an error? I'd be interested to know what approaches and techniques people are using to work around this issue.
Given that Google are encouraging the adoption of HTTPS how should we proceed without alienating users that have poorly configured systems?
I have an app, and it makes an https connection to a server. Is it possible to use something like wireshark or charlesproxy to just see the useragent that it's connecting with? I don't want to see any of the actual data, just the useragent - but I'm not sure if that is encrypted as well? (and if it's worth trying)
Thanks
Is it possible to...
No. Browser first establishes secure connection with server, then use it for transfer all data including requests' data, various headers etc.
Too late for the original inquirer, but the answer is that it may be possible in some cases, depending on application implementation.
You can use fiddler, and by turning on the 'decrypt https traffic' you also have visibility to the HTTPS content in some cases.
What fiddler does (on windows at least) is register itself within the wininet as system proxy. It can also add certificates (requires your approval when you select to decrypt https traffic) and generates on the fly certificates for the accessed domains, thus being MitM.
Applications using this infrastructure will be 'exposed' to this MitM. I ran fiddler and ran a few applications and was able to view https traffic related to office products (winword, powerpoint, outlook) other MS executables (Searchprotocolhost.exe) but also to some non-microsoft products such as apple software update, cisco jabber)