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.
Related
I try to read the website https://www.eroids.com/reviews with Indy and always get a 403.
This website seems only to load when I set the ssl version to sslvTLSv1_1. If I do that, this website loads fine, but other websites not. Most other seems to use sslvTLSv1_2.
As long I only add [sslvTLSv1_1] to the sslversion, it works, but when I add [sslvTLSv1_1, sslvTLSv1_2], the mentioned site does not load anymore (again 403), but any other site does.
My question is: How can I determine what sslversion a website need? Do I need to try to access the site with each ssl version until I get a 200 back or is there something to me unknown integrated into indy to automatically do that?
How can I determine what sslversion a website need?
In general, you can't. However, most servers support version negotiation during the TLS handshake, so that clients supporting multiple/different TLS versions can negotiate with the server for which TLS version to use. But, it sounds like maybe this particular server does not support that.
However, the fact that you are even getting an HTTP 403 response at all for an HTTPS url means a TLS session is being created fine, so the issue is something else.
Unless the server is ignoring all TLS errors during the handshake and creating a simple TLS session, THEN is sending an HTTP error in reply to an earlier TLS error. Which is rare, but not unheard of.
Do I need to try to access the site with each ssl version until I get a 200 back
In this particular situation, probably so, yes. Start with [sslvTLSv1_1, sslvTLSv1_2], and if that fails then retry with [sslvTLSv1_2], then retry with [sslvTLSv1_1], and so on.
is there something to me unknown integrated into indy to automatically do that?
Indy does not have that capability at this time, no.
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 have a very strange problem.
I've tried to test HTTP/2 with Chrome using this URL : https://http2.akamai.com/demo
It tells me that the browser doesn't have HTTP/2 enabled but it's activated by default in last version of Chrome.
I've tested with Firefox and I have the same problem.
That's weird because it works with Chrome on Mobile ...
Does anyone have a clue ?
Thanks for your help
You are likely not connecting directly to the server and have either a proxy (if at a company computer) or anti-virus software which is downgrading your connection.
For the latter you can normally disable HTTPS traffic sniffing to avoid this. Of course that loses the protection of that traffic sniffing though some say the intercepting it does for HTTPS traffic sniffing causes more harm than it solves and a well patched computer should not need this.
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)