suyashkumar / ssl-proxy Goto Github PK

Usage of ./ssl-proxy:
  -cert string
        path to a tls certificate file. If not provided, ssl-proxy will generate one for you in ~/.ssl-proxy/
  -domain string
        domain to mint letsencrypt certificates for. Usage of this parameter implies acceptance of the LetsEncrypt terms of service.
  -from string
        the tcp address and port this proxy should listen for requests on (default "127.0.0.1:4430")
  -key string
        path to a private key file. If not provided, ssl-proxy will generate one for you in ~/.ssl-proxy/
  -redirectHTTP
        if true, redirects http requests from port 80 to https at your fromURL
  -to string
        the address and port for which to proxy requests to (default "http://127.0.0.1:80")

The help text says that the files will be created in ~/.ssl-proxy, but they are created in current working directory.

2022/03/02 20:26:18 http: TLS handshake error from 138.246.253.24:41988: acme/autocert: missing server name

Wrap this line in log.Fatal

In it's present state ssl-proxy is by default vulnerable to a lot of attacks (as revealed by running e.g. testssl.sh against it).

IMHO ssl-proxy should therefore use reasonably secure TLS defaults, i.e.

• TLS >= 1.2
• A set of cipher suites without known vulnerabilities (i.e. des/3des, rc4, cbc ciphers should not be offered)

I have a Wyse thin client running a web management console on https 443

Nothing in the modern age will talk to it as it's using a very old SSL/TLS self-signed cert from 2011.

I tried using ssl-proxy to connect but still run into issues with the old ciphers not being accepted. Is there any way to do this?

(130)(deck@steamdeck Documents)$ ./ssl-proxy-linux-amd64 -from 127.0.0.1:4430 -to https://192.168.100.37:443
2023/06/16 19:27:37 No existing cert or key specified, generating some self-signed certs for use (cert.pem, key.pem)
2023/06/16 19:27:37 SHA256 Fingerprint: DE 64 E7 91 F8 AE 49 4C C9 5A 11 3E 78 5E 17 BD A4 F1 8F 30 CB 6E 8B AD 87 86 9A 87 F5 CC 14 8A
2023/06/16 19:27:37 Proxying calls from https://127.0.0.1:4430 (SSL/TLS) to https://192.168.100.37:443
2023/06/16 19:27:48 http: TLS handshake error from 127.0.0.1:44164: remote error: tls: unknown certificate
2023/06/16 19:27:50 http: TLS handshake error from 127.0.0.1:58938: remote error: tls: unknown certificate
2023/06/16 19:27:50 http: proxy error: tls: server selected unsupported protocol version 300

I've the same issue of that issue #36, and i'm trying using the last version of ssl-proxy-linux-amd64 realese 0.2.7 and building from source with last commit 09cb9a.

The ssl-proxy was running fine, then i stopped, and when i started ssl-proxy again, show that error.

Using my cert and key works fine.

sudo ssl-proxy -from 0.0.0.0:443 -to 127.0.0.1:8080 -domain=testhome.com -redirectHTTP
2020/03/31 17:05:28 Assuming -to URL is using http://
2020/03/31 17:05:28 Proxying calls from https://0.0.0.0:443 (SSL/TLS) to http://127.0.0.1:8080
2020/03/31 17:05:28 Domain specified, using LetsEncrypt to autogenerate and serve certs for testhome.com
2020/03/31 17:05:28 Also redirecting https requests on port 80 to https requests on 0.0.0.0:443
2020/03/31 17:06:19 http: TLS handshake error from 192.168.1.64:43046: acme/autocert: unable to satisfy "https://acme-v02.api.letsencrypt.org/acme/authz-v3/3682531274" for domain "testhome.com": no viable challenge type found

When I build the latest master-revision a4f8529 via Docker, I get the following error when executing the Linux-Binary:

./ssl-proxy-linux-amd64: No such file or directory

In my use-case I provide a private key and a certificate-chain but even without those parameters the error message remains the same (hence, the error doesn't seem to be related to loading one of those files).

I tried building with the following versions of docker and docker-compose:

On Linux (Debian Buster):

• Docker version 20.10.6, build 370c289
• docker-compose version 1.29.2, build 5becea4c

On Windows (10):

• Docker version 20.10.14, build a224086
• docker-compose version 1.29.2, build 5becea4c

hi, i unable to install because domain https://getbin.io seems to be dead!.

I would love to see a support for websockets.

Hello , i understand the benefits of using load balancers but i wondering since most sites don't have a lot of requests per second can i use this proxy instead because am really lazy and this is very easy, lets say my api for example is made in go ( meaning the default go-app server can handle for example 60k req/s) and my site receives around a maximum of 3k req /s then using this proxy seems a viable option for me or? what would you advice me to do and thanks for this application.

It would be much better to use a docker builder pattern to reduce the size of the image to the minimum. Also would be nice to publish an official image on docker hub.

the documentation says it uses ~/.ssl-proxy/ to store cert/key, but it actually just dumps them in the cwd

when type go get or build i get this error : ./main.go:105:16: m.TLSConfig undefined (type *autocert.Manager has no field or method TLSConfig) please help resolve thanks

It would be nice if I could create an SSL proxy for arbitrary TCP traffic, rather than just HTTP.

when I have only one site need to do reverse proxy , ssl-proxy works like a charm !
but I have no idea how to run ssl-proxy for multiple sites in one public ip ?
eg something like
w1.abc.com 127.0.0.1:4000
w2.abc.com 127.0.0.1:5000

I can do ssl-proxy -from 0.0.0.0:443 -to 127.0.0.1:4000 -domain w1.abc.com, but how to add w2.abc.com ?

is it possible to do so ?

I try and proxy 127.0.0.1:8000, but the output says http://127.0.0.1:80:

$ ./ssl-proxy-darwin-amd64 ssl-proxy -from 0.0.0.0:4430 -to 127.0.0.1:8000
2021/05/18 16:41:51 No existing cert or key specified, generating some self-signed certs for use (cert.pem, key.pem)
2021/05/18 16:41:51 SHA256 Fingerprint: E2 53 60 35 CF 6B 2F 90 FB CE 46 AD 3A 00 10 45 48 E5 C5 11 50 1D 8B 0A B2 3C 27 8F 11 FB F8 9C
2021/05/18 16:41:51 Proxying calls from https://127.0.0.1:4430 (SSL/TLS) to http://127.0.0.1:80

I used this proxy before and everything was working like a charm...now when i come back to run it doesnt work.

This is my webserver..

This is the ssl proxy running

What i get when i go to http://api.codingsett.codes

I am using that docker container https://github.com/AddisMap/ssl-proxy-docker/tree/patches with

-from 0.0.0.0:443 -redirectHTTP -domain example.com

Now it would redirect to https://0.0.0.0:443

-from example.com:443

would not work, because it cannot bind to the address (maybe because it's in the docker container)

Can't we just use the -domain value for redirection?

This may add some extra security for transient self-signed cert applications (jupyter sessions?).

I use ssl-proxy on a robot. Since it doesn't have a real-time clock, it syncs its time over ntp after booting.

To avoid letsencrypt rate limiting, ssl-proxy should sanity check to make sure that the date is set to after 1970 before requesting certificates.

See also: golang/go#28201

A tragedy in log file format on machine reboot:

1970/01/01 00:00:09 Assuming -to URL is using http://
1970/01/01 00:00:09 Proxying calls from https://[::]:443 (SSL/TLS) to http://127.0.0.1:8000
1970/01/01 00:00:09 Domain specified, using LetsEncrypt to autogenerate and serve certs for foo.example.com
1970/01/01 00:00:09 Also redirecting https requests on port 80 to https requests on foo.example.com
1970/01/01 00:00:19 http: TLS handshake error from [fe80::1234]:57129: acme/autocert: missing certificate
1970/01/01 00:00:19 http: TLS handshake error from [fe80::1234]:57128: Get "https://acme-v02.api.letsencrypt.org/directory": x509: certificate has expired or is not yet valid: current time 1970-01-01T00:00:18Z is before 2022-04-26T22:21:59Z
1970/01/01 00:00:19 http: TLS handshake error from [fe80::1234]:57130: acme/autocert: missing certificate
1970/01/01 00:00:19 http: TLS handshake error from [fe80::1234]:57131: acme/autocert: missing certificate
1970/01/01 00:00:20 http: TLS handshake error from [fe80::1234]:57132: acme/autocert: missing certificate
1970/01/01 00:00:20 http: TLS handshake error from [fe80::1234]:57133: acme/autocert: missing certificate
1970/01/01 00:00:20 http: TLS handshake error from [fe80::1234]:57134: acme/autocert: missing certificate
1970/01/01 00:00:20 http: TLS handshake error from [fe80::1234]:57135: acme/autocert: missing certificate
1970/01/01 00:00:23 http: TLS handshake error from [fe80::1234]:57138: acme/autocert: missing certificate
1970/01/01 00:00:23 http: TLS handshake error from [fe80::1234]:57136: acme/autocert: missing certificate
1970/01/01 00:00:23 http: TLS handshake error from [fe80::1234]:57137: acme/autocert: missing certificate
1970/01/01 00:00:23 http: TLS handshake error from [fe80::1234]:57139: acme/autocert: missing certificate
1970/01/01 00:00:23 http: TLS handshake error from [fe80::1234]:57141: acme/autocert: missing certificate
1970/01/01 00:00:23 http: TLS handshake error from [fe80::1234]:57140: acme/autocert: missing certificate
2022/05/02 03:56:00 http: TLS handshake error from [fe80::1234]:57142: acme/autocert: missing certificate
2022/05/02 03:56:00 http: TLS handshake error from [fe80::1234]:57143: acme/autocert: missing certificate
2022/05/02 03:56:00 http: TLS handshake error from [fe80::1234]:57144: acme/autocert: missing certificate
2022/05/02 03:56:00 http: TLS handshake error from [fe80::1234]:57145: acme/autocert: missing certificate
2022/05/02 03:56:05 http: TLS handshake error from [fe80::1234]:57146: acme/autocert: missing certificate
2022/05/02 03:56:05 http: TLS handshake error from [fe80::1234]:57147: acme/autocert: missing certificate
2022/05/02 03:56:06 http: TLS handshake error from [fe80::1234]:57148: acme/autocert: missing certificate
2022/05/02 03:56:06 http: TLS handshake error from [fe80::1234]:57149: acme/autocert: missing certificate
2022/05/02 03:56:08 http: TLS handshake error from [fe80::1234]:57150: acme/autocert: missing certificate
2022/05/02 03:56:08 http: TLS handshake error from [fe80::1234]:57151: acme/autocert: missing certificate
2022/05/02 03:56:12 http: TLS handshake error from [fe80::1234]:57152: acme/autocert: missing certificate
2022/05/02 03:56:12 http: TLS handshake error from [fe80::1234]:57153: acme/autocert: missing certificate
2022/05/02 03:56:15 http: TLS handshake error from [fe80::1234]:57181: acme/autocert: missing certificate
2022/05/02 03:56:15 http: TLS handshake error from [fe80::1234]:57182: acme/autocert: missing certificate
2022/05/02 03:56:16 http: TLS handshake error from [fe80::1234]:57184: acme/autocert: missing certificate
2022/05/02 03:56:16 http: TLS handshake error from [fe80::1234]:57185: acme/autocert: missing certificate
2022/05/02 03:56:18 http: TLS handshake error from [fe80::1234]:57186: acme/autocert: missing certificate
2022/05/02 03:56:18 http: TLS handshake error from [fe80::1234]:57187: acme/autocert: missing certificate
2022/05/02 03:56:22 http: TLS handshake error from [fe80::1234]:57188: acme/autocert: missing certificate
2022/05/02 03:56:22 http: TLS handshake error from [fe80::1234]:57189: acme/autocert: missing certificate
2022/05/02 03:56:29 http: TLS handshake error from [fe80::1234]:57190: acme/autocert: missing certificate
2022/05/02 03:56:29 http: TLS handshake error from [fe80::1234]:57191: acme/autocert: missing certificate
2022/05/02 03:56:29 http: TLS handshake error from [fe80::1234]:57192: acme/autocert: missing certificate
2022/05/02 03:56:29 http: TLS handshake error from [fe80::1234]:57194: acme/autocert: missing certificate
2022/05/02 03:56:29 http: TLS handshake error from [fe80::1234]:57193: acme/autocert: missing certificate
2022/05/02 03:56:29 http: TLS handshake error from [fe80::1234]:57195: acme/autocert: missing certificate
2022/05/02 03:56:30 http: TLS handshake error from [fe80::1234]:57196: acme/autocert: missing certificate
2022/05/02 03:56:30 http: TLS handshake error from [fe80::1234]:57197: acme/autocert: missing certificate
2022/05/02 03:56:30 http: TLS handshake error from [fe80::1234]:57198: acme/autocert: missing certificate
2022/05/02 03:56:30 http: TLS handshake error from [fe80::1234]:57199: acme/autocert: missing certificate
2022/05/02 03:56:32 http: TLS handshake error from [fe80::1234]:57201: acme/autocert: missing certificate
2022/05/02 03:56:32 http: TLS handshake error from [fe80::1234]:57202: acme/autocert: missing certificate
2022/05/02 03:56:32 http: TLS handshake error from [fe80::1234]:57203: acme/autocert: missing certificate
2022/05/02 03:56:32 http: TLS handshake error from [fe80::1234]:57204: acme/autocert: missing certificate
2022/05/02 03:56:36 http: TLS handshake error from [fe80::1234]:57216: acme/autocert: missing certificate
2022/05/02 03:56:36 http: TLS handshake error from [fe80::1234]:57217: acme/autocert: missing certificate
2022/05/02 03:56:36 http: TLS handshake error from [fe80::1234]:57218: acme/autocert: missing certificate
2022/05/02 03:56:36 http: TLS handshake error from [fe80::1234]:57221: acme/autocert: missing certificate
2022/05/02 03:56:41 http: TLS handshake error from [fe80::1234]:57234: acme/autocert: missing certificate
2022/05/02 03:56:41 http: TLS handshake error from [fe80::1234]:57235: acme/autocert: missing certificate
2022/05/02 03:56:42 http: TLS handshake error from [fe80::1234]:57236: acme/autocert: missing certificate
2022/05/02 03:56:42 http: TLS handshake error from [fe80::1234]:57237: acme/autocert: missing certificate
2022/05/02 03:56:44 http: TLS handshake error from [fe80::1234]:57238: acme/autocert: missing certificate
2022/05/02 03:56:44 http: TLS handshake error from [fe80::1234]:57239: acme/autocert: missing certificate
2022/05/02 03:56:48 http: TLS handshake error from [fe80::1234]:57240: acme/autocert: missing certificate
2022/05/02 03:56:48 http: TLS handshake error from [fe80::1234]:57241: acme/autocert: missing certificate
2022/05/02 04:01:53 http: TLS handshake error from [fe80::1234]:57336: acme/autocert: missing certificate
2022/05/02 04:01:53 http: TLS handshake error from [fe80::1234]:57244: acme/autocert: missing certificate
2022/05/02 04:01:53 http: TLS handshake error from [fe80::1234]:57329: acme/autocert: missing certificate
2022/05/02 04:01:53 http: TLS handshake error from [fe80::1234]:57478: acme/autocert: missing certificate
2022/05/02 04:01:53 http: TLS handshake error from [fe80::1234]:57247: acme/autocert: missing certificate
2022/05/02 04:01:53 http: TLS handshake error from [fe80::1234]:57242: 429 urn:ietf:params:acme:error:rateLimited: Error creating new order :: too many certificates (5) already issued for this exact set of domains in the last 168 hours: foo.example.com: see https://letsencrypt.org/docs/rate-limits/
2022/05/02 04:01:53 http: TLS handshake error from [fe80::1234]:57273: acme/autocert: missing certificate

A feature should be added to support redirection of all HTTP traffic on port 80 to HTTPS traffic on 443. Will look into how generalizable this sort of traffic redirection should be across ports.

Heyja, I think the problem (#36) is present again with newest version 0.5.2.

Connecting from WIN Agent to Linux Proxy with -autocert.

-selfcert works fine!

Error Proxy:
ligolo-ng » 2024/02/18 23:56:55 [ERR] yamux: Failed to write header: acme/autocert: missing server name
2024/02/18 23:56:55 [ERR] yamux: Failed to read header: acme/autocert: missing server name
ERRO[0259] could not register agent, error: acme/autocert: missing server name

Error Agent:
./agent-windows.exe -connect 10.10.16.158:11601

agent-windows.exe : time="2024-02-18T14:56:55-08:00" level=info msg="Connection established" addr="10.10.16.158:11601"
+ CategoryInfo : NotSpecified: (time="2024-02-1...0.16.158:11601":String) [], RemoteException
+ FullyQualifiedErrorId : NativeCommandError
2024/02/18 14:56:56 [ERR] yamux: Failed to read header: remote error: tls: internal error
time="2024-02-18T14:56:56-08:00" level=error msg="Connection error: remote error: tls: internal error"
time="2024-02-18T14:56:56-08:00" level=fatal msg="remote error: tls: internal error"

Thanks for the work!

Consider using the create-release action to automatically create releases for ssl-proxy.

When building the Docker image from 83836bc, I get:

$ docker build -t my/ssl-proxy .
[...]
Step 6/6 : RUN make
 ---> Running in 0cc1b0b6fa3d
go mod download
warning: pattern "all" matched no module dependencies
go build -o ssl-proxy
main.go:16:2: cannot find package "golang.org/x/crypto/acme/autocert" in any of:
        /usr/local/go/src/golang.org/x/crypto/acme/autocert (from $GOROOT)
        /go/src/golang.org/x/crypto/acme/autocert (from $GOPATH)
make: *** [Makefile:6: build] Error 1
The command '/bin/sh -c make' returned a non-zero code: 2

This is on Ubuntu 18.04.4, using Docker version 18.09.7, build 2d0083d (from the Ubuntu repository).

Unable to curl using the command in the README
curl -LJ "https://getbin.io/suyashkumar/ssl-proxy?os=linux" | tar xvz

I get Connection timed out

Hi, I found this awesome project, but when trying to run it on a CentOS 4 server where anything else have problems, it seems this binary also has issues. Is there any way that I can get this with no system dependencies:

./ssl-proxy -cert /usr/local/tomcat7/certs/xxxx.crt -key /usr/local/tomcat7/certs/xxxx.key -from 0.0.0.0:8443 -to 127.0.0.1:8080
2018/10/26 14:43:29 Assuming -to URL is using http://
2018/10/26 14:43:29 Proxying calls from https://0.0.0.0:8443 (SSL/TLS) to http://127.0.0.1:8080
2018/10/26 14:43:29 open /usr/local/tomcat7/certs/xxxx.crt: function not implemented