how to make tinyproxy support https proxy?

[luckypoem]

root@p1601860745:~# tinyproxy -v
tinyproxy 1.11.0-rc1-40-git-563978a
root@p1601860745:~#

in the 'about' section of https://github.com/tinyproxy/tinyproxy , it says: "tinyproxy - a light-weight HTTP/HTTPS proxy daemon", so how to make tinyproxy support https proxy?
i don't know how i should edit tinyproxy.conf?

[rofl0r]

tinyproxy is a HTTP proxy, but it allows connections to HTTPS endpoints via CONNECT method. that's why HTTPS is mentioned. it is by itself not a "HTTPS proxy", but it can be turned into one by using something like stunnel in front of it, just like stunnel can turn a HTTP server into a HTTPS server.

[kowoba]

Hm - but it does act as a HTTPS proxy, right? At least I have the following setup, which works with https:

legacy retro client - RFC1918 IPv4 link - modern linux with tinyproxy, IPv6-only connectivity to the world

The legacy IPv4-only client manage to reach websites "out there" over https and IPv6, via tinyproxy on the linux box.

[rofl0r]

Hm - but it does act as a HTTPS proxy, right?

as i said, tinyproxy can talk to HTTPS endpoints just fine, it just doesn't by itself listen on encrypted port. so the difference is only whether you specify in your proxy-using application whether tinyproxy is a https or http proxy (or for command line apps like curl using the environment variable https_proxy vs http_proxy) - the former would try to do a TLS handshake with tinyproxy itself, which isn't supported. whether your application does TLS with the TCP endpoint tinyproxy connects to, doesn't concern tinyproxy at all and works fine.

[stokito]

FYI: I understood how it works after reading this two articles
https://en.wikipedia.org/wiki/Opportunistic_TLS
https://en.wikipedia.org/wiki/HTTP_tunnel

[Torxgewinde]

Hello and thanks for TinyProxy which I really like.

I'd like to authenticate users accessing the proxy. TinyProxy supports basic-auth for that. The credentials are easily recovered/sniffed if TinyProxy does not support TLS. I am aware ot putting stunnel in front of tinyproxy. Is this a design decision to not add TLS in order to keep TinyProxy tiny? I know adding TLS adds dependencies and increases the footprint, however I regard encryption even in a LAN a necessity nowadays.

I would like to know, if not having TLS is a strict design decision, or if just no one had time to implement it yet and PRs would be considered.

[stokito]

@Torxgewinde this is confusing but basically the "HTTPS proxy" is just the same as HTTP and just raw traffic without changing anything. The only thing that proxy makes is the first command CONNECT https://example.com/ and after that connects and just resends all data.

That means that the TLS encryption is performed by a client e.g. browser. And this is even better because the proxy can't read anything. The only security problem is that eavesdropper can see to which website you are trying to connect.

It was called "HTTPS proxy" just because it means that when it sees the CONNECT https:// it will connect to 443 port instead instead 80. There is literally no any TLS code inside.

[rofl0r]

I would like to know, if not having TLS is a strict design decision, or if just no one had time to implement it yet and PRs would be considered.

yes, it's by design and by unix philosophy to do one thing and do it well. adding TLS on the listening side can be easily achieved using other tools, without complicating the code and adding dependencies.

[Torxgewinde]

@stokito Thank you for the quick reply. Indeed this is for the connection from the client to the proxy which I'd like to have encrypted. Daniel Stenberg, describes it very short. Firefox, Chromium and curl support this and it is especially the https_proxy I am looking for.

@rofl0r Yes, the stunnel scenario is a feasible workaround to protect the authentication data. Using stunnel is however not ideal, as it involves a bit more configuration for users. For example the WolfSSL library does not add a lot of overhead as it is intended to be used with embedded devices and it would be one additional dependency. OpenWRT does use it at several places for example and they provide binaries with and without TLS for many packages. Using the WolfSSL library seems not overly complicated according to a basic example. Would you agree, that TinyProxy might benefit from offering TLS? That way the TinyProxy daemon could be located not only in a LAN, but even in a wider network where eavesdropping is possible. The basic-auth data could still be used for authentication, but it is protected against sniffers. In my opinion adding TLS to the listening socket of TinyProxy is worth one additional dependency. However, I can also understand your decision if the main goal is to keep TinyProxy as tiny as possible.

[rofl0r]

the main issue with TLS libs is that they hide the underlying socket and you need to use special functions like tls_recv etc to interface with the TLS library, which then accesses the socket. so you need different code paths for TLS and non-TLS sockets, and can't even use poll/select to relay data back and forth between both sockets. additionally tinyproxy has lots of optional features such as transparent proxying, reverse proxy, etc which all will much likely require additional logic for TLS use.
as far as having an encrypted AND authenticated tunnel to the http proxy is concerned, TLS isn't the only solution. i heard success stories from people using credir together with tinyproxy.

[Torxgewinde]

credir is nice, no doubt. It is very tiny and could even be fully incorporated. TweetNaCLs idea is to be so tiny, that it just fits everywhere. Major drawback of this is, each client needs to provide the matching endpoint. But a proxy is also useful for restricted and limited devices, like for instance iOS mobile phones - on such devices deviating from the standard is nearly not doable.

I agree, certainly adding a TLS library will increase code complexity, memory footprint and more CPU cycles. Questions is: Is it something that makes TinyProxy "better"? To me it would, that's the reason I'd like to suggest heading towards it.

[stokito]

Is it something that makes TinyProxy "better"?

not really. You can even now configure the https_proxy and see in Wireshark what happens. You'll see only the CONNECT line and all other messages will be encrypted.
In fact in windows the http_proxy and https_proxy are always the same.
That means that if you add MbedTLS support it won't work anyway because a client doesn't expect any MiTM proxy.

[Torxgewinde]

All good.

I still would appreciate if TinyProxy at some stage gets the TLS option to:

• encrypt credentials to access to the proxy itself,
• to encrypt the SNI/certificate during the TLS/HELLO-phase even in HTTPS connections that are established by CONNECT and
• to encrypt plain HTTP traffic between the proxy and the client.

As modular solution one can use stunnel as described here.

Regardless TinyProxy is very useful to me as it nicely fits on embedded hardware, thank you for that and keep up the good work. Bye!

[stokito]

I agree, but this also needs for a client support.
BTW does anybody used the stunnel? It seems like not a truly open source solution. Also it uses OpenSSL but would be nice to have MbedTLS which is included to OpenWrt out of the box.
Maybe something instead can be used.
The BusyBox has ssl_helper that looks like copied from WolfSSL (MatrixSSL).

[dtklein]

I think there is a little confusion, with two (main) meanings of TLS proxying.

1. The proxy takes connections from the user agent on a TLS socket, typically regardless of whether the origin is a TLS-protected resource or a plaintext resource. This is what was described in the conversation above. Because the connection is encrypted end-to-end, the proxy cannot inspect the communications for filtering, caching, etc
2. The proxy "bumps" the TLS connection. That is, the proxy server terminates the TLS connection, using an ephemeral certificate, issued by a PKI Certificate Authority trusted by the user agent, which vouches for the identity of the origin. The proxy then initiates a separate TLS connection to the origin, on behalf of the user agent. This enables the proxy server to stand-in, in between the ua and origin. This can be thought of as a "sanctioned man-in-the-middle", and enables traffic inspection for use cases like

• Malware scanning
• Data-leak prevention
• Caching of static assets
• Corporate policy enforcement

To perform bumping, the solution would need significant additional code to add capabilities like:

• Secure key-storage (or integration with a mechanism for key-storage)
• Retrieval and inspection of origin certificate
• PKI Certificate Authority to issue the ephemeral certificate
• In-memory storage of ephemeral certificates and deliberate age-out / destruction of ephemeral certificates after configured lifetime

You would additionally want to add the ability to classify origin domains into categories, and enable/disable TLS bumping by category (for example, corporate policy might elect to not bump health or financial sites for employee privacy, drop or redirect connections for file-sharing for DLP, and pass software downloading through virus scanner and license review).

These capabilities are similar to commercial proxy solutions, and help make a proxy a truly enterprise tool that is part of a security toolset.

Adding TLS bumping and site classification would likely increase the size, scope and complexity of this small, svelte, fast solution. Moreover, it would increase the operational complexity of deploying and operating the solution.