HUD forces HTTPS when connecting to port 443 that is HTTP only

[smandon]

Describe the bug I'm trying to use zaproxy to test an HTTP server running on port 443 but it automatically changes the request to use HTTPS, which obviously fails. This is not coming from the browser (firefox in my case) as it works perfectly as long as i'm not proxying through zaproxy, and it's not a server redirection as it doesn't have SSL/TLS at all, I also checked with wireshark, and I can only see packets for the SSL/TLS negociation.

To Reproduce

1. Run an HTTP server on port 443 without any SSL/TLS
2. Try to connect to it with zaproxy as proxy via URL http://server:443
3. Displays zaproxy "Connection Refused" error where you can clearly see it tries to connect with HTTPS and you can see the browser changed the URL to https://server

Expected behavior Should connect via HTTP without trying to force HTTPS

Software versions

• ZAP: latest zaproxy weekly D-2019-02-25
• OS: Kali Linux
• Java: openjdk 11.0.2
• Browser: Firefox 60.5.0esr 64-bit

[psiinon]

@smandon is that with the HUD turned on? If so can you try again with the HUD turned off? You can turn it off via the 'radar' icon on the top toolbar.

[smandon]

It was with the HUD turned on (by default). It works if I turn it off.

[psiinon]

@smandon thanks for reporting this. We've just moved it as the HUD issues are in its own repo.

[ztgrace]

I'd like to add an additional scenario to this issue, but we can split it off if you feel it's appropriate.

Here's the scenario I've just run into:

• App is running on port 8080 without TLS
• Loading the page with HUD enabled results in a 302 redirect to port 8080 with TLS enabled
• Site does not support TLS over 8080 and fails to load

Disabling HUD fixes the issue.

While I do like the idea of attempting to upgrade the connection, there at least needs to be an easy way to disable this automatic upgrade within the HUD itself.

[psiinon]

@ztgrace we have to upgrade the connection to https in order for the HUD to work. However ZAP should handle this internally even if the application doesnt. It looks like in your case ZAP isnt handling it correctly. Are there any errors in the zap.log file? https://github.com/zaproxy/zaproxy/wiki/FAQhelp#check-the-log-file

[ztgrace]

No relevant errors in the zap.log that I can see.

I did a little more investigation on the endpoint. It looks like it does support TLS on that port too from a web server perspective, however the app is not being served when accessing over TLS. So I think ZAP interprets the successful handshake as a successful upgrade to TLS, but it's an unusable state because of the misconfiguration of the application.

This might be an unusual edgecase, but I think having a manual override would be a straightforward way of dealing with misconfiguration oddities.

[psiinon]

Yeah, we could have an option for ZAP to handle the https comms even if a site appears to support it.

[knuckerr]

same issue here the site wont load because the site does not support TLS and when the HUD is enable the page don't load when is disable everything is fine

[psiinon]

@knuckerr have you got the latest version of the HUD? The HUD should handle the TLS side even if your site doesnt. The latest version of the HUD has some fixes in, but if these dont work then some more info would be appreciated, such as if there are any errors in the zap.log file or in the browser console.

[knuckerr]

this happen when i install the lasted version of the HUD the previous version worked fine !. here is the zap.log file and the console logs of the website i visit Strict-Transport-Security: The connection to the site is untrustworthy, so the specified header was ignored. cookieconsent.min.css Strict-Transport-Security: The connection to the site is untrustworthy, so the specified header was ignored. jquery.min.js Strict-Transport-Security: The connection to the site is untrustworthy, so the specified header was ignored. cookieconsent.min.js Strict-Transport-Security: The connection to the site is untrustworthy, so the specified header was ignored. icon zap.log

[psiinon]

Thats weird, and not what I expected at all :( None of the errors in the zap.log file or those browser console message look relevant. Can you tell why the site wont load? Eg via the browser network tab?

[knuckerr]

in the browser network tab everything is fine but now i look in the console log again and i catch a new error 15:23:29 GMT+0300 (Eastern European Summer Time) ERROR errorHandler: Error: Could not find any clients for frameId: drawer NoClientIdError@https: https://zap//zapCallBackUrl/5620533657504872500?name=utils.js 14:4 messageAllTabs https://zap//zapCallBackUrl/5620533657504872500?name=utils.js 488:1: {} 5620533657504872500:718:35 log https://zap//zapCallBackUrl/5620533657504872500?name=utils.js:718 errorHandler https://zap//zapCallBackUrl/5620533657504872500?name=utils.js:690

[sp0tt13]

Using OWASP ZAP 2.9.0 against a site which is operating as http (with incomplete https config). The very first request for a HTTP GET seems to be converted to a 302 response to the browser by ZAP to redirect to the https version of the site... which eventually fails. So just confirming the above that the HUD is responsible for this as turning this off leaves the browser in http mode (which is what I want).

The only exception in the ZAP log is the result of a subsequent API call on the misconfigured https (which it is not intended to serve)... 2020-02-26 18:14:16,149 [ZAP-ProxyThread-3237] WARN ProxyThread - An exception occurred while attempting to connect to: https://localhost:6017/api/applications The exception was: Unrecognized SSL message, plaintext connection? Root cause: SSLException: Unrecognized SSL message, plaintext connection? The following document may be of assistance in resolving this failure: https://www.zaproxy.org/faq/how-to-connect-to-an-https-site-that-reports-a-handshake-failure/

[awgh]

This turned out to be what was making it impossible for me to use Zap 2.10.0 against OWASP WebGoat/WebWolf running on localhost via HTTP. Zap would redirect to HTTPS and then the connection would fail.

So... issue still exists in 2.10.0, and you can repro quite easily by running WebGoat on localhost 8080 and trying to connect to it via Zap. Disabling the HUD solved the issue.

[adiffpirate]

Just ran into the same issue. I'm also using 2.10.0. Any workarounds found?

[ChrisAD]

I've got this issue with 2.10.0 .. I disabled extensions related to HUD, restarted ZAP and it no longer rewrites HTTP to HTTPS.

To test, simply access http://neverssl.com through ZAP and it will try access it via HTTPS.

[kingthorin]

neverssl.com works just fine for me with HUD:

HUD's TLS upgrades are only client-side.

If that isn't working for you then you have a config/install issue I believe.

[kingthorin]

@ChrisAD were you using a browser launched from ZAP? Or did you manually configure your browser?

If manual, try a launched browser.

[nbering]

I stumbled upon this issue myself, while integrating ZAP into my development environment.

I'm using a Zap in Docker with Webswing, with ZAP between a Traefik proxy and the web application, so there's a proxy chain something like this:

http://localhost:8080/ -> http://zap:8090/ -> http://web:3000/

The official ZAP Docker image has HUD installed and enabled, and was redirecting http://localhost:8080 to https://localhost:8080. Disabling HUD fixed the issue for me.

At the moment, I have to remove HUD every time I start up the docker container fresh, or figure out how to modify the base image to disable HUD. Ideally, I'd love to see this fixed so no one else has to track this down if they're on the same path as me.

[qbeukes]

It would indeed be nice if we can have a settings toggle to disable this http->https redirect when using HUD. The HUD is very useful so not being able to use it for localhost during active development forces me to switch between the browser and Swing GUI repeatedly.

Having to add an HTTPS listener each time purely for running on localhost is not ideal because our AWS Load Balancers take care of that. I imagine a toggle to disable the HUD redirect can't be very complicated, can it? If someone can confirm this I'll even volunteer my time to implement a PR for this issue.

Are there any complications involved in fixing this ancient issue?