-
Notifications
You must be signed in to change notification settings - Fork 96
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question about transparent SSL/TLS proxying without decryption #35
Comments
Please see the filtering rules in SSLproxy 0.9.0 (and structured filtering rules on the develop branch to be released soon with v0.9.1). Note that the Passthrough mode is for fail-open configuration for SSL/TLS errors, that's all (if there is no SSL/TLS error, it does not pass the connection through). So, first, I suggest you use a config file, instead of command line. And in the config file add a rule like the following:
which should engage the Passthrough mode for all connections originating from 172.16.1.1 (fail-open or not). I'll see if I need to clarify the documentation for the Passthrough mode. |
Initially I used config file but I thought it would be easier to test it if I provide command line arguments. No matter what I try, I get almost thousand lines like this:
followed by a single line:
and after that, almost thousand lines like this:
Config file looks like this:
And this is the command line I am using: I decided to post the question here because I wasn't sure whether I am doing something wrong or SSLproxy doesn't support passthrough without certificate forging. On the client side I get this:
|
I don't see any problem with your sslproxy configuration (at least as far as I can see). But if you get the Also, can you test with a target address/port proxyspec like And also, perhaps you can first test with plain HTTP, instead of HTTPS, to rule out ssl cert issues. (I have tried |
Hello!
First, thank you for the effort and time invested in SSLproxy project.
I went through the available documentation and did some testing but I am unable to conclude if it's possible to achieve transparent SSL/TLS proxying with SSLproxy without content decryption (and without forging of SSL certificates).
I have spent some time playing with the options such as
-o Divert=no
and-o Passthrough=yes
as I assumed that if the diverting is turned off and passing through is turned on, the traffic would be "simply" transparently forwarded to the target server running https service.I have setup something like this using SSLproxy 0.9 on the Centos Linux 7.9 x86_64 with kernel 3.10.0-1160.42.2.el7.x86_64:
This is the command I used (as root) on the Proxy server:
sslproxy -D4 -c /etc/sslproxy/certs/ca.crt -k /etc/sslproxy/certs/ca.key -C /etc/pki/tls/cert.pem -o Divert=no -o Passthrough=yes -o VerifyPeer=no -P https 192.168.1.1 443
For testing purposes on the Client server I used curl and the /etc/hosts file had a line
192.168.1.1 dns.google
The curl command looked like:
curl -v https://dns.google:443
The Proxy server is able to properly resolve domain names and to connect to https services on the Internet.
Note that for the purpose of explaining the issue I used different IP addresses and URL but it doesn't really matter.
I didn't use any specific iptables rules as I wanted the SSLproxy to listen on 192.168.1.1:443
Upon execution of the curl command on the Client server, the above setup would result with SSLproxy momentarily opening all remaining ~1024 file descriptors and the client would get the error stating that the connection was reset.
What am I missing?
My goal was to pass the https traffic from Client to the Server via SSLproxy and use its filtering feature without decrypting the actual content (I assume that SNI makes this possible).
Kind regards!
The text was updated successfully, but these errors were encountered: