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?
Related
I have recently been sharing the connection of my mobile device to my laptop, when i'm out and about, through the use of an app called netshare. It provides a https proxy I believe through which it acts as a network repeater?(not sure about this part). I can access webpages and such quite easily. However, I have realised that I cannot connect to some apps. For example, I cannot use spotify. Installing some other apps like games etc also prove to fail. I have done a bit of research and found that apparently I could only surf the web with a https proxy. However, I found this to be unambiguous. Does this mean that I can only make https requests? Or is this because of https using TCP over UDP? What are the limitations and what can I do to possibly solve it?
Thanks
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
I am creating a JSF application deployed in Tomcat/EE (with CLIENTCERTs). By default, the jsessionid (generated with a SecureRandom, so it looks safe) was set in the URL, which I disabled for security reasons by changing the SessionTrackingMode.
Now I am trying to find the security advantages/disadvantages of using:
<tracking-mode>SSL</tracking-mode> vs. <tracking-mode>COOKIE</tracking-mode>
(considering security almost always has an impact on performance and other variables). Probably one of the problems is that I do not know what SSL tracking-mode exactly does. This API documentation is not very clear.
When should I use one or the other?
PS: I know this is not specific of Tomcat or JSF but I need to give context to the question
I would recommend the use of cookie-based session-tracking over SSL session-tracking for a few reasons:
Using SSL session-tracking may prevent explicit (user-initiated) logouts
Using SSL session-tracking may prevent sessions from being terminated due to inactivity-timeouts
Using SSL session-tracking may cause unexpected logouts (due to TLS renegotiation, which changes the TLS session-id)
Using SSL session-tracking will make it harder to debug, troubleshoot, and generally manipulate your own application if necessary (telling a client to clear their cookies is easier and less arcane than asking them to expire their TLS session-ids)
FWIW, IBM WebSphere has dropped support for SSL-based session-tracking as of version 7.0 (circa 2008).
I don't see any advantage to using SSL-based session-tracking.
I would like to add some details to #Christopher Schultz's answer.
If your application is not using client certificates, then it might be more convenient to use cookies. The reason is potential invalidation of sessions as Christopher pointed out. I have not tested this, though, it is just a theoretical impression.
If client certificates are used, I have verified that tracking sessions via SSL connections is completely valid. I have been doing this for a while and I have not found any problem, nor unexpected error/logout, nor tedious process for users to have to login again. In my opinion, in some situations SSL might even be a cleaner way to keep
sessions. Note that developers might have to keep some security
considerations when using cookies (e.g. HttpOnly, cookie secure
flag...). I am not saying this is a reason to choose SSL
tracking, since developers might have to keep some security
considerations with SSL tracked sessions too, I am just saying I am
not currently aware of them, while I am aware of the cookie ones.
If you opt for SSL tracking and you are using JSF (Java EE) and e.g. #ViewScopeds, then you will have problems when using the insecure HTTP, because JSF will not be able to track the session if no TLS/SSL is in place. So if you need JSF with scopes that need tracking the session, and need HTTP access to your application, then you should go for COOKIE tracking. On the other hand, if you always use HTTPS, or have no need to e.g. #ViewScoped, then SSL tracking is totally fine.
I have an https site that needs data from an API that is only available in http.
To get around the mixed content warning, I changed it so the JS requests a path on the server, which then makes the http request and returns the data.
Is this bad? If it is bad, why?
My understanding of what you're doing :
You are providing a HTTPS url on your server which is essentially acting as a proxy, making a backend connection between your server and the API provider over HTTP.
If my understanding of what you're doing is correct, then what you're doing is better than just serving everything over HTTP...
You are providing security between the client and your server. Most security threats that would take advantage of a plain HTTP connection are in the local environment of the client - such as on a shared local network. Dodgy wifi in a cafe. School lans. etc.
The connection between your server and the API provider is unencrypted but apparently they only provide that unencrypted anyway. This is really the best you can do unless your API provider starts providing an HTTPS interface.
It's more secure than doing nothing and should eliminate the browser errors.
If there is a real need for security (PCI compliance, HIPAA etc) however, you should stop using that API. However it seems unlikely considering the circumstantial evidence in your question.
I am working on a project where the user will transfer his username to activate the internet. I want to always redirect the user to the https version and make the http version redirect to the https aswell, so there is only an http version. Is this a smart move? Could there be problems with mobile devices (WiFi enabled devices)
Thomas
I don't think that there are many devices which don't support ssl. There are some stupidly configured proxies, though.
Most site aren't "complete ssl" because of server load, ssl can bring a server to its knees really fast.
If you're transmitting secure data, then it's definitely smart to to redirect to HTTPS. As a hacker, you'd immediately look for the easiest opening in a site. In this case, it would be attacking any devices that are excepted from the SSL rule.