Proxomitron Reborn

[amy]

4.6.0.1 has been released! Merry Christmas!

Changes in this release:
- Generate certificate serial number from hostname
- Always add SAN to certificates
- Fix buffer overflow in request parsing
- Fix adding manually entered blockfile entries
- Fix parsing of CONNECT URLs
- Fix listener startup message

(Dec. 24, 2018 01:47 PM)whenever Wrote:  Maybe let the HTTPS thread not write the status?

That is what I've done for 4.6.0.1. You will still see two messages in the log when you abort (which restarts the listeners) if you have both ports enabled, however.

(Dec. 24, 2018 01:47 PM)whenever Wrote:  Maybe build a URL at this step? If we see just a path, is it safe to assume the hostname is just local.ptron?

Also, the URL matching is handled inside the HTTPS server while not by the Proxy server (because of "SSL Pass-Thru")? Is this the same way how the program handle pure http local.ptron requests? I had thought the matching/filtering was done by the proxy server.

Yes, that might be possible but like I said earlier, I still don't understand the request processing code sufficiently and it might break some other things if I change it. For non-local HTTPS requests, the listener goes into secure mode and then reads the request, and URL matching is done there. For local HTTPS requests, the listener goes into bypass mode, hence no URL matching is done by it. Your suggestions have been logged for version 5.x improvements.

(Dec. 24, 2018 01:47 PM)whenever Wrote:  A little curious when it will initiate a remote connection?

When it receives a CONNECT request that isn't local.ptron, or a request with a full hostname (e.g. GET http://example.com/ HTTP/1.1)... I think.

(Dec. 24, 2018 01:47 PM)whenever Wrote:  Also, http://local.ptron is not exposed to the outside via port 80 so you can't use http://127.0.0.1:80 to access it. The new https addition (Thank you!) is making its service available via https://127.0.0.1:8443 and I'm not sure if it's a good idea. It may expose security risks. What about making it available only via https://local.ptron, or making it an option? For example, if we set the https port number to 0, it just disable the external service while the internal service is always available via https://local.ptron (at default port 443).

The access controls for both listeners are managed by the settings under the Access tab.

Quote:

---

BTW, I have been getting this several times.

That is unusual. Does it occur with Scott's original? Is it just the UI not getting drawn (i.e. you can still click where the buttons would be and they work), or do the controls not even respond?

(Dec. 24, 2018 07:01 PM)mizzmona Wrote:  Just thought of something for the wish list, no rush or anything...

Strict byte-value matches for checking uppercase vs lowercase (e.g., [%41] vs [%61]).

If you can come up with a precise detailed specification of the syntax and behaviour, preferably one which won't break existing patterns, then I can consider adding it in the next feature release (4.6.1).

(Dec. 25, 2018 05:47 AM)JJoe Wrote:  Best solution would be to have the Access dialog control both.

That's how it currently works.