{"id":13577106,"url":"https://github.com/sonertari/SSLproxy","last_synced_at":"2025-04-05T09:31:04.261Z","repository":{"id":37270329,"uuid":"101116604","full_name":"sonertari/SSLproxy","owner":"sonertari","description":"Transparent SSL/TLS proxy for decrypting and diverting network traffic to other programs, such as UTM services, for deep SSL inspection","archived":false,"fork":false,"pushed_at":"2024-12-19T20:02:29.000Z","size":3032,"stargazers_count":415,"open_issues_count":47,"forks_count":103,"subscribers_count":15,"default_branch":"master","last_synced_at":"2025-03-31T22:17:47.215Z","etag":null,"topics":["mitm","ssl-inspection","ssl-proxy","sslsplit","tls-proxy","transparent-proxy"],"latest_commit_sha":null,"homepage":"","language":"C","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"bsd-2-clause","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/sonertari.png","metadata":{"files":{"readme":"README.md","changelog":"NEWS.md","contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":"SECURITY.md","support":null,"governance":null,"roadmap":null,"authors":"AUTHORS.md","dei":null,"publiccode":null,"codemeta":null}},"created_at":"2017-08-22T23:31:20.000Z","updated_at":"2025-03-20T07:17:50.000Z","dependencies_parsed_at":"2023-12-27T16:28:20.701Z","dependency_job_id":"ab480b26-22dc-4810-bd53-2173f554ff27","html_url":"https://github.com/sonertari/SSLproxy","commit_stats":null,"previous_names":[],"tags_count":27,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sonertari%2FSSLproxy","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sonertari%2FSSLproxy/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sonertari%2FSSLproxy/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sonertari%2FSSLproxy/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/sonertari","download_url":"https://codeload.github.com/sonertari/SSLproxy/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":247318084,"owners_count":20919448,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["mitm","ssl-inspection","ssl-proxy","sslsplit","tls-proxy","transparent-proxy"],"created_at":"2024-08-01T15:01:18.066Z","updated_at":"2025-04-05T09:30:59.248Z","avatar_url":"https://github.com/sonertari.png","language":"C","funding_links":[],"categories":["C"],"sub_categories":[],"readme":"# SSLproxy - transparent SSL/TLS proxy for decrypting and diverting network traffic to other programs for deep SSL inspection [![Build Status](https://travis-ci.com/sonertari/SSLproxy.svg?branch=master)](https://app.travis-ci.com/github/sonertari/SSLproxy)\n\nCopyright (C) 2017-2024, [Soner Tari](mailto:sonertari@gmail.com).\nhttps://github.com/sonertari/SSLproxy\n\nCopyright (C) 2009-2019, [Daniel Roethlisberger](//daniel.roe.ch/).\nhttps://www.roe.ch/SSLsplit\n\n## Overview\n\nSSLproxy is a proxy for SSL/TLS encrypted network connections. It is intended \nto be used for decrypting and diverting network traffic to other programs, such \nas UTM services, for deep SSL inspection. But it can handle unencrypted \nnetwork traffic as well.\n\n[The UTMFW project](https://github.com/sonertari/UTMFW) uses SSLproxy to \ndecyrpt and feed network traffic into its UTM services: Web Filter, POP3 \nProxy, SMTP Proxy, and Inline IPS; and also indirectly into Virus Scanner and \nSpam Filter through those UTM software. Given that most of the Internet \ntraffic is encrypted now, without SSLproxy it wouldn't be possible to deeply \ninspect most of the network traffic passing through UTMFW.\n\nSee [this presentation](https://drive.google.com/open?id=12YaGIGs0-xfpqMNAY3rzUbIyed-Tso8W) \nfor a summary of SSL interception and potential issues with middleboxes that \nsupport it.\n\n### Mode of operation\n\nSSLproxy is designed to transparently terminate connections that are redirected\nto it using a network address translation engine. SSLproxy then terminates\nSSL/TLS and initiates a new SSL/TLS connection to the original destination\naddress. Packets received on the client side are decrypted and sent to the\nprogram listening on a port given in the proxy specification. SSLproxy inserts\nin the first packet the address and port it is expecting to receive the packets\nback from the program. Upon receiving the packets back, SSLproxy re-encrypts\nand sends them to their original destination. The return traffic follows the\nsame path back to the client in reverse order.\n\n![Mode of Operation Diagram](https://drive.google.com/uc?id=1N_Yy5nMPDSvY8YaNFd4sHvipyLWq5zDy)\n\nThis is similar in principle to [divert \nsockets](https://man.openbsd.org/divert.4), where the packet filter diverts the \npackets to a program listening on a divert socket, and after processing the \npackets the program reinjects them into the kernel. If there is no program \nlistening on that divert socket or the program does not reinject the packets \ninto the kernel, the connection is effectively blocked. In the case of \nSSLproxy, SSLproxy acts as both the packet filter and the kernel, and the \ncommunication occurs over networking sockets.\n\nSSLproxy supports split mode of operation similar to SSLsplit as well. In \nsplit mode, packets are not diverted to listening programs, effectively making \nSSLproxy behave similar to SSLsplit, but not exactly like it, because SSLproxy \nhas certain features non-existent in SSLsplit, such as user authentication, \nprotocol validation, and filtering rules. Also, note that the implementation \nof the proxy core in SSLproxy is different from the one in SSLsplit; for \nexample, the proxy core in SSLproxy runs lockless, whereas SSLsplit \nimplementation uses a thread manager level lock (which does not necessarily \nmake sslproxy run faster than sslsplit). In SSLproxy, split mode can be \ndefined globally, per-proxyspec, or per-connection using filtering rules.\n\nSSLproxy does not automagically redirect any network traffic.  To actually\nimplement a proxy, you also need to redirect the traffic to the system running \nsslproxy.  Your options include running sslproxy on a legitimate router, ARP \nspoofing, ND spoofing, DNS poisoning, deploying a rogue access point (e.g. \nusing hostap mode), physical recabling, malicious VLAN reconfiguration or \nroute injection, /etc/hosts modification and so on.\n\n#### Proxy specifications\n\nSSLproxy supports three different types of proxy specifications, or proxyspecs \nfor short, which can be in divert or split style.\n\n- Command line proxyspecs passed on the command line\n- One line proxyspecs in configuration files\n- Structured proxyspecs in configuration files\n\nThe syntax of command line proxyspecs is as follows:\n\n\t(tcp|ssl|http|https|pop3|pop3s|smtp|smtps|autossl)\n\t  listenaddr listenport\n\t  [up:divertport [ua:divertaddr ra:returnaddr]]\n\t  [(targetaddr targetport|sni sniport|natengine)]\n\nThe syntax of one line proxyspecs is the same as the syntax of command line \nproxyspecs, except for the leading `ProxySpec` keyword:\n\n\tProxySpec (tcp|ssl|http|https|pop3|pop3s|smtp|smtps|autossl)\n\t  listenaddr listenport\n\t  [up:divertport [ua:divertaddr ra:returnaddr]]\n\t  [(targetaddr targetport|sni sniport|natengine)]\n\nThe syntax of structured proxyspecs is as follows, and they can configure \nconnection options too:\n\n\tProxySpec {\n\t    Proto (tcp|ssl|http|https|pop3|pop3s|smtp|smtps|autossl)\n\t    Addr listenaddr       # inline\n\t    Port listenport       # comments\n\t    DivertPort divertport # allowed\n\t    DivertAddr divertaddr\n\t    ReturnAddr returnaddr\n\t    TargetAddr targetaddr\n\t    TargetPort targetport\n\t    SNIPort sniport\n\t    NatEngine natengine\n\n\t    # Divert or split\n\t    Divert (yes|no)\n\n\t    # Connection options\n\t    Passthrough (yes|no)\n\n\t    DenyOCSP (yes|no)\n\t    CACert ca.crt\n\t    CAKey ca.key\n\t    ClientCert client.crt\n\t    ClientKey client.key\n\t    CAChain chain.crt\n\t    LeafCRLURL http://example.com/example.crl\n\t    DHGroupParams dh.pem\n\t    ECDHCurve prime256v1\n\t    SSLCompression (yes|no)\n\t    ForceSSLProto (ssl2|ssl3|tls10|tls11|tls12|tls13)\n\t    DisableSSLProto (ssl2|ssl3|tls10|tls11|tls12|tls13)\n\t    EnableSSLProto (ssl2|ssl3|tls10|tls11|tls12|tls13)\n\t    MinSSLProto (ssl2|ssl3|tls10|tls11|tls12|tls13)\n\t    MaxSSLProto (ssl2|ssl3|tls10|tls11|tls12|tls13)\n\t    Ciphers MEDIUM:HIGH\n\t    CipherSuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256\n\t    VerifyPeer (yes|no)\n\t    AllowWrongHost (yes|no)\n\n\t    RemoveHTTPAcceptEncoding (yes|no)\n\t    RemoveHTTPReferer (yes|no)\n\t    MaxHTTPHeaderSize 8192\n\t    ValidateProto (yes|no)\n\n\t    UserAuth (yes|no)\n\t    UserTimeout 300\n\t    UserAuthURL https://192.168.0.1/userdblogin.php\n\n\t    # The DivertUsers, PassUsers, and PassSite options will be deprecated\n\t    DivertUsers userlist\n\t    PassUsers userlist\n\t    PassSite rules\n\n\t    Define $macro valuelist\n\n\t    (Divert|Split|Pass|Block|Match) one line filtering rules\n\t    FilterRule {...} structured filtering rules\n\t}\n\nFor example, given the following command line proxyspec:\n\n\thttps 127.0.0.1 8443 up:8080\n\n- SSLproxy listens for HTTPS connections on 127.0.0.1:8443.\n- Upon receiving a connection from the Client, it decrypts and diverts the \npackets to a Program listening on 127.0.0.1:8080. The default divert address \nis 127.0.0.1, which can be configured by the `ua` option.\n- After processing the packets, the Program gives them back to SSLproxy \nlistening on a dynamically assigned address, which the Program obtains from \nthe SSLproxy line in the first packet in the connection.\n- Then SSLproxy re-encrypts and sends the packets to the Server.\n\nThe response from the Server follows the same path back to the Client in \nreverse order.\n\nSplit style proxyspecs configure for split mode of operation similar to \n[SSLsplit](https://github.com/droe/sslsplit). See the SSLsplit documentation \nfor the details of split style proxyspecs.\n\n#### SSLproxy line\n\nGiven the proxyspec example above, a sample line SSLproxy inserts into the \nfirst packet in the connection may be the following:\n\n\tSSLproxy: [127.0.0.1]:34649,[192.168.3.24]:47286,[192.168.111.130]:443,s\n\n- The first IP:port pair is a dynamically assigned address that SSLproxy \nexpects the program send the packets back to it.\n- The second and third IP:port pairs are the actual source and destination \naddresses of the connection, respectively. Since the program receives the \npackets from SSLproxy, it cannot determine the source and destination \naddresses of the packets by itself, for example by asking the NAT engine, \nhence must rely on the information in the SSLproxy line.\n- The last letter is either s or p, for SSL/TLS encrypted or plain traffic, \nrespectively. This information is also important for the program, because it \ncannot reliably determine if the actual network traffic it is processing was \nencrypted or not before being diverted to it.\n\n#### Listening programs\n\nThe program that packets are diverted to should support this mode of operation.\nSpecifically, it should be able to recognize the SSLproxy address in the first\npacket, and give the first and subsequent packets back to SSLproxy listening \non that address, instead of sending them to their original destination as it \nnormally would.\n\nYou can use any software as a listening program as long as it supports this \nmode of operation. So existing or new software developed in any programming \nlanguage can be modified to be used with SSLproxy to inspect and/or modify any \nor all parts of the packets diverted to it.\n\nGiven the proxyspec example above, a program should be listening on port 8080.\n\nYou can offload the system SSLproxy is running on by diverting packets to \nremote listening programs too. For example, given the following proxy \nspecification:\n\n\thttps 127.0.0.1 8443 up:8080 ua:192.168.0.1 ra:192.168.1.1\n\n- The `ua` option instructs SSLproxy to divert packets to 192.168.0.1:8080, \ninstead of 127.0.0.1:8080 as in the previous proxyspec example.\n- The `ra` option instructs SSLproxy to listen for returned packets from the \nprogram on 192.168.1.1, instead of 127.0.0.1 as in the previous SSLproxy line.\n\nAccordingly, the SSLproxy line now becomes (notice the first IP address):\n\n\tSSLproxy: [192.168.1.1]:34649,[192.168.3.24]:47286,[192.168.111.130]:443,s\n\nAnd a listening program should be running at address 192.168.0.1 on port 8080.\n\nSo, the listening program can be running on a machine anywhere in the world. \nSince the packets between SSLproxy and the listening program are always \nunencrypted, you should be careful while using such a setup.\n\n### Protocols\n\n#### Supported protocols\n\nSSLproxy supports plain TCP, plain SSL, HTTP, HTTPS, POP3, POP3S, SMTP, and \nSMTPS connections over both IPv4 and IPv6. It also has the ability to \ndynamically upgrade plain TCP to SSL in order to generically support SMTP \nSTARTTLS and similar upgrade mechanisms. Depending on the version of OpenSSL, \nSSLproxy supports SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2, and TLS 1.3, and \noptionally SSL 2.0 as well. SSLproxy supports Server Name Indication (SNI), \nbut not Encrypted SNI in TLS 1.3. It is able to work with RSA, DSA and ECDSA \nkeys and DHE and ECDHE cipher suites.\n\nThe following features of SSLproxy are IPv4 only:\n\n- Divert addresses for listening programs in proxyspecs\n- SSLproxy return addresses dynamically assigned to connections\n- IP addresses in the ua and ra options\n- IP and ethernet addresses of clients in user authentication\n- Target IP and ethernet addresses in mirror logging\n\n#### OCSP, HPKP, HSTS, Upgrade et al.\n\nSSLproxy implements a number of defences against mechanisms which would\nnormally prevent MitM attacks or make them more difficult. SSLproxy can deny\nOCSP requests in a generic way. For HTTP and HTTPS connections, SSLproxy\nmangles headers to prevent server-instructed public key pinning (HPKP), avoid\nstrict transport security restrictions (HSTS), avoid Certificate Transparency\nenforcement (Expect-CT) and prevent switching to QUIC/SPDY, HTTP/2 or\nWebSockets (Upgrade, Alternate Protocols). HTTP compression, encodings and\nkeep-alive are disabled to make the logs more readable.\n\nAnother reason to disable persistent connections is to reduce file descriptor \nusage. Accordingly, connections are closed if they remain idle for a certain \nperiod of time. The default timeout is 120 seconds, which can be configured by \nthe ConnIdleTimeout option.\n\n#### Protocol validation\n\nProtocol validation makes sure the traffic handled by a proxyspec is using the \nprotocol specified in that proxyspec. If a connection cannot pass protocol \nvalidation, it is terminated. To enable protocol validation, the ValidateProto \noption can be defined globally, per-proxyspec, or per-connection using \nfiltering rules. This feature currently supports HTTP, POP3, and SMTP \nprotocols.\n\nSSLproxy uses only client requests for protocol validation. However, it also \nvalidates SMTP responses until it starts processing the packets from the \nclient. If there is no excessive fragmentation, the first couple of packets in \nthe connection should be enough for validating protocols.\n\n### Certificates\n\n#### Certificate forging\n\nFor SSL and HTTPS connections, SSLproxy generates and signs forged X509v3\ncertificates on-the-fly, mimicking the original server certificate's subject\nDN, subjectAltName extension and other characteristics. SSLproxy has the\nability to use existing certificates of which the private key is available,\ninstead of generating forged ones. SSLproxy supports NULL-prefix CN\ncertificates but otherwise does not implement exploits against specific\ncertificate verification vulnerabilities in SSL/TLS stacks.\n\n#### Certificate verification\n\nSSLproxy verifies upstream certificates by default. If the verification fails,\nthe connection is terminated immediately. This is in contrast to SSLsplit,\nbecause in order to maximize the chances that a connection can be successfully\nsplit, SSLsplit accepts all certificates by default, including self-signed\nones. See [The Risks of SSL Inspection](https://insights.sei.cmu.edu/cert/2015/03/the-risks-of-ssl-inspection.html)\nfor the reasons for this difference. You can enable or disable this feature by \nthe VerifyPeer option, which can be defined globally, per-proxyspec, or \nper-connection using filtering rules.\n\n#### Client certificates\n\nSSLproxy uses the certificate and key from the pemfiles configured by the \nClientCert and ClientKey options when the destination requests client \ncertificates. These options can be defined globally, per-proxyspec, or \nper-connection using filtering rules.\n\nAlternatively, you can use Pass filtering rules to pass through certain \ndestinations requesting client certificates.\n\n### User authentication\n\nIf the UserAuth option is enabled, SSLproxy requires network users to log in \nto the system to establish connections to the external network.\n\nSSLproxy determines the user owner of a connection using a `users` table in an \nSQLite3 database configured by the UserDBPath option. The users table should \nbe created using the following SQL statement:\n\n\tCREATE TABLE USERS(\n\t   IP             CHAR(45)     PRIMARY KEY     NOT NULL,\n\t   USER           CHAR(31)     NOT NULL,\n\t   ETHER          CHAR(17)     NOT NULL,\n\t   ATIME          INT          NOT NULL,\n\t   DESC           CHAR(50)\n\t);\n\nSSLproxy does not create this users table or the database file by itself, nor \ndoes it log users in or out. So the database file with the users table should \nalready exist at the location pointed to by the UserDBPath option. An external \nprogram should log users in and out on the users table. The external program \nshould fill out all the fields in user records, except perhaps for the DESC \nfield, which can be left blank.\n\nWhen SSLproxy accepts a connection,\n\n- It searches the client IP address of the connection in the users table. If \nthe client IP address is not in the users table, the connection is redirected \nto a login page configured by the UserAuthURL option.\n- If SSLproxy finds a user record for the client IP address in the users \ntable, it obtains the ethernet address of the client IP address from the arp \ncache of the system, and compares it with the value in the user record for \nthat IP address. If the client IP address is not in the arp cache, or the \nethernet addresses do not match, the connection is redirected to the login \npage.\n- If the ethernet addresses match, SSLproxy compares the atime value in the \nuser record with the current system time. If the difference is greater than \nthe value configured by the UserTimeout option, the connection is redirected \nto the login page.\n\nIf the connection passes all these checks, SSLproxy proceeds with establishing \nthe connection.\n\nThe atime of the IP address in the users table is updated with the system time \nwhile the connection is being terminated. Since this atime update is executed \nusing a privsep command, it is expensive. So, to reduce the frequency of such \nupdates, it is deferred until after the user idle time is more than half of \nthe timeout period.\n\nIf a description text is provided in the DESC field, it can be used with \nfiltering rules to treat the user logged in from different locations, i.e. \nfrom different client IP addresses, differently.\n\nIf the UserAuth option is enabled, the user owner of the connection is \nappended at the end of the SSLproxy line, so that the listening program can \nparse and use this information in its logic and/or logging:\n\n\tSSLproxy: [127.0.0.1]:34649,[192.168.3.24]:47286,[192.168.111.130]:443,s,soner\n\nThe user authentication feature is currently available on OpenBSD and Linux \nonly.\n\n### Filtering rules\n\nSSLproxy can divert, split, pass, block, or match connections based on \nfiltering rules. Filtering rules can be defined globally and/or per-proxyspec.\n\n- `Divert` action diverts packets to the listening program, allowing SSL \ninspection by the listening program and content logging of packets\n- `Split` action splits the connection but does not divert packets to the \nlistening program, effectively disabling SSL inspection by the listening \nprogram, but allowing content logging of packets\n- `Pass` action passes the connection through by engaging passthrough mode, \neffectively disabling SSL inspection and content logging of packets\n- `Block` action terminates the connection\n- `Match` action specifies log actions and/or connection options for the \nconnection without changing its filter action\n\nSSLproxy supports one line and structured filtering rules.\n\nThe syntax of one line filtering rules is as follows:\n\n\t(Divert|Split|Pass|Block|Match)\n\t ([from (\n\t     user (username[*]|$macro|*) [desc (desc[*]|$macro|*)]|\n\t     desc (desc[*]|$macro|*)|\n\t     ip (clientip[*]|$macro|*)|\n\t     *)]\n\t  [to (\n\t     (sni (servername[*]|$macro|*)|\n\t      cn (commonname[*]|$macro|*)|\n\t      host (host[*]|$macro|*)|\n\t      uri (uri[*]|$macro|*)|\n\t      ip (serverip[*]|$macro|*)) [port (serverport[*]|$macro|*)]|\n\t     port (serverport[*]|$macro|*)|\n\t     *)]\n\t  [log ([[!]connect] [[!]master] [[!]cert]\n\t        [[!]content] [[!]pcap] [[!]mirror] [$macro]|[!]*)]\n\t  |*) [# comment]\n\nThe syntax of structured filtering rules is as follows, and they can configure \nconnection options too:\n\n\tFilterRule {\n\t    Action (Divert|Split|Pass|Block|Match)\n\n\t    # From\n\t    User (username[*]|$macro|*)  # inline\n\t    Desc (desc[*]|$macro|*)      # comments\n\t    SrcIp (clientip[*]|$macro|*) # allowed\n\n\t    # To\n\t    SNI (servername[*]|$macro|*)\n\t    CN (commonname[*]|$macro|*)\n\t    Host (host[*]|$macro|*)\n\t    URI (uri[*]|$macro|*)\n\t    DstIp (serverip[*]|$macro|*)\n\t    DstPort (serverport[*]|$macro|*)\n\n\t    # Multiple Log lines allowed\n\t    Log ([[!]connect] [[!]master] [[!]cert]\n\t         [[!]content] [[!]pcap] [[!]mirror] [$macro]|[!]*)\n\n\t    ReconnectSSL (yes|no)\n\n\t    # Connection options\n\t    Passthrough (yes|no)\n\n\t    DenyOCSP (yes|no)\n\t    CACert ca.crt\n\t    CAKey ca.key\n\t    ClientCert client.crt\n\t    ClientKey client.key\n\t    CAChain chain.crt\n\t    LeafCRLURL http://example.com/example.crl\n\t    DHGroupParams dh.pem\n\t    ECDHCurve prime256v1\n\t    SSLCompression (yes|no)\n\t    ForceSSLProto (ssl2|ssl3|tls10|tls11|tls12|tls13)\n\t    DisableSSLProto (ssl2|ssl3|tls10|tls11|tls12|tls13)\n\t    EnableSSLProto (ssl2|ssl3|tls10|tls11|tls12|tls13)\n\t    MinSSLProto (ssl2|ssl3|tls10|tls11|tls12|tls13)\n\t    MaxSSLProto (ssl2|ssl3|tls10|tls11|tls12|tls13)\n\t    Ciphers MEDIUM:HIGH\n\t    CipherSuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256\n\t    VerifyPeer (yes|no)\n\t    AllowWrongHost (yes|no)\n\n\t    RemoveHTTPAcceptEncoding (yes|no)\n\t    RemoveHTTPReferer (yes|no)\n\t    MaxHTTPHeaderSize 8192\n\t    ValidateProto (yes|no)\n\n\t    UserAuth (yes|no)\n\t    UserTimeout 300\n\t    UserAuthURL https://192.168.0.1/userdblogin.php\n\t}\n\nThe specification of which connections a filtering rule will be applied to is \nachieved by the `from` and `to` parts of the filtering rule and by the \nproxyspec that the rule is defined for.\n\n- The `from` part of a rule defines source filter based on client IP address, \nuser and/or description, or `*` for all.\n- The `to` part defines destination filter based on server IP and/or port, SNI \nor Common Names of SSL connections, Host or URI fields in HTTP Request \nheaders, or `*` for all.\n\t+ Dst Host type of rules use the `ip` site field\n\t+ SSL type of rules use the `sni` or `cn` site field\n\t+ HTTP type of rules use the `host` or `uri` site field\n\t+ All rule types can use the `port` field\n- The proxyspec handling the connection defines the protocol filter for the \nconnection.\n\nIf and how a connection should be logged is specified using the `log` or \n`Log` part of one line or structured filtering rules, respectively:\n\n- `connect` enables logging connection information to connect log file\n- `master` enables logging of master keys\n- `cert` enables logging of generated certificates\n- `content` enables logging packet contents to content log file\n- `pcap` enables writing packets to pcap file\n- `mirror` enables mirroring packets to mirror interface or target\n\nYou can add a negation prefix `!` to a log action to disable that logging.\n\nStructured filtering rules can also specify connection options to be \nselectively applied to matching connections, not just globally or \nper-proxyspec. One line filtering rules cannot specify connection options.\n\nFor example, if the following rules are defined in a structured HTTPS proxyspec,\n\n\tSplit from user soner desc notebook to sni example.com log content\n\tPass from user soner desc android to cn .fbcdn.net*\n\nThe first filtering rule above splits but does not divert HTTPS connections \nfrom the user `soner` who has logged in with the description `notebook` to SSL \nsites with the SNI of `example.com`. Also, the rule specifies that the packet \ncontents of the matching connection be written to content log file configured \nglobally.\n\nThe second rule passes through HTTPS connections from the user `soner` who has \nlogged in with the description `android` to SSL sites with the Common Names \ncontaining the substring `.fbcdn.net` anywhere in it (notice the asterisk at \nthe end). Since connection contents cannot be written to log files in \npassthrough mode, the rule does not specify any content log action.\n\nThe default filter action is Divert. So, if those are the only filtering rules \nin that proxyspec, the other connections are diverted to the listening program \nspecified in that proxyspec, without writing any logs.\n\nIf you want to enable, say, connect logging for the other connections handled \nby that proxyspec, without changing their default Divert filter action, you \ncan add a third filtering rule to that proxyspec:\n\n\tMatch * log connect\n\nNote that the second example above is a filtering rule you can use to resolve \none of the certificate issues preventing the Facebook application on Android \nsmartphones to connect to the Internet from behind sslproxy.\n\nFiltering rules are applied based on certain precedence orders:\n\n- More specific rules have higher precedence. Log actions increase rule \nprecedence too.\n- The precedence of filter types is as HTTP \u003e SSL \u003e Dst Host. Because, the \napplication order of filter types is as Dst Host \u003e SSL \u003e HTTP, and a filter \ntype can override the actions of a preceding filter type.\n- The precedence of filter actions is as Divert \u003e Split \u003e Pass \u003e Block. This is \nonly for the same type of filtering rules.\n- The precedence of site fields is as sni \u003e cn for SSL filter and host \u003e uri \nfor HTTP filter.\n\nFor example, the pass action of a Dst Host filter rule is taken before the \nsplit action of an SSL filter rule with the same from definition, due to the \nprecedence order of filter types. Or, the pass action of a rule with sni site \nfield is taken before the split action of the same rule with cn site field, due \nto the precedence order of site fields.\n\nPass and Block filter actions are deferred until the last moment they can be \napplied to a connection, so that Divert and Split filter actions can override \nthem.\n\nIn terms of possible filter actions,\n\n- Dst Host filtering rules can take all of the filter and log actions.\n- SSL filtering rules can take all of the filter and log actions.\n- HTTP filtering rules can take match and block filter actions, can keep \nenabled divert and split modes, but cannot take pass action. Also, HTTP \nfiltering rules can only disable logging.\n\nLog actions do not configure any loggers. Global loggers for respective log \nactions should have been configured for those log actions to have any effect.\n\nIf no filtering rules are defined for a proxyspec, all log actions for that \nproxyspec are enabled. Otherwise, all log actions are disabled, and filtering \nrules should enable them specifically.\n\nTo increase rule reuse, one or more of SNI, CN, Host, URI, and DstIp site \nfields can be specified in the same structured filtering rule.\n\nConnection options specified in a structured filtering rule can have any \neffect only if the rule matches the connection before global or proxyspec \nconnection options are applied. Otherwise, the global or proxyspec connection \noptions already applied to a connection cannot be overriden by the connection \noptions specified in the matching structured filtering rule. For example, SSL \noptions of a connection cannot be changed after the SSL connection is \nestablished. So, normally SSL type of rules cannot modify SSL options of a \nconnection, but you can use the ReconnectSSL option to reconnect the server \nside of an SSL connection to enforce the SSL options in the SSL type of \nfiltering rules. In other words, the ReconnectSSL option allows for using the \nSNI and CN fields in stuctured filtering rules to match SSL connections and \nchange their SSL configuration.\n\nMacro expansion is supported. The `Define` option can be used for defining \nmacros to be used in filtering rules. Macro names must start with a `$` sign. \nThe macro name must be followed by words separated by spaces.\n\nYou can append an asterisk `*` to the fields in filtering rules for substring \nmatching. Otherwise, the filter searches for an exact match with the field in \nthe rule. The filter uses B-trees for exact string matching and Aho-Corasick \nmachines for substring matching.\n\nThe ordering of filtering rules is important. The ordering of from, to, and \nlog parts of one line filtering rules is not important. The ordering of log \nactions is not important.\n\nIf the UserAuth option is disabled, only client IP addresses can be used in \nthe from part of filtering rules.\n\n#### Excluding sites from SSL inspection\n\nPassSite option is a special form of Pass filtering rule. PassSite rules can \nbe written as Pass filtering rules. The PassSite option will be deprecated in \nfavor of filtering rules in the future.\n\nPassSite option allows certain SSL sites to be excluded from SSL inspection. \nIf a PassSite rule matches the SNI or Common Names in the SSL certificate of a \nconnection, the connection is passed through the proxy without being diverted \nto the listening program. SSLproxy engages the Passthrough mode for that \npurpose. For example, sites requiring client authentication can be added as \nPassSite rules.\n\nPer-site filters can be defined using client IP addresses, users, and \ndescription. If the UserAuth option is disabled, only client IP addresses can \nbe used in PassSite filters. Multiple sites can be defined, one on each line. \nPassSite rules can search for exact or substring matches, but do not support \nmacro expansion.\n\n#### User control lists\n\nUser control lists can be implemented using filtering rules. The DivertUsers \nand PassUsers options will be deprecated in favor of filtering rules in the \nfuture.\n\nDivertUsers and PassUsers options can be used to divert, pass through, or \nblock users.\n\n- If neither DivertUsers nor PassUsers is defined, all users are diverted to \nlistening programs.\n- Connections from users in DivertUsers, if defined, are diverted to listening \nprograms.\n- Connections from users in PassUsers, if defined, are simply passed through \nto their original destinations. SSLproxy engages the Passthrough mode for that \npurpose.\n- If both DivertUsers and PassUsers are defined, users not listed in either of \nthe lists are blocked. SSLproxy simply terminates their connections.\n- If *no* DivertUsers list is defined, only users *not* listed in PassUsers \nare diverted to listening programs.\n\nThese user control lists can be defined globally or per-proxyspec. User \ncontrol lists do not support macro expansion.\n\n### Logging\n\nLogging options include connect and content log files as well as PCAP files \nand mirroring decrypted traffic to a network interface. Additionally, \ncertificates, master secrets and local process information can be logged. \nFiltering rules can selectively modify connection logging.\n\nSee the manual pages `sslproxy(1)` and `sslproxy.conf(5)` for details on using \nSSLproxy, setting up the various NAT engines, and for examples.\n\n\n## Requirements\n\nSSLproxy depends on the OpenSSL, libevent 2.x, libpcap, libnet 1.1.x, and \nsqlite3 libraries by default. Libpcap and libnet are not needed if the \nmirroring feature is omitted. Sqlite3 is not needed if the user authentication \nfeature is omitted. The build depends on GNU make and a POSIX.2 environment \nin `PATH`. If available, pkg-config is used to locate and configure the \ndependencies. The optional unit tests depend on the check library. The \noptional end-to-end tests depend on the [TestProxy](https://github.com/sonertari/TestProxy) \ntool, and are supported on Linux only.\n\nSSLproxy currently supports the following operating systems and NAT mechanisms:\n\n- FreeBSD: pf rdr and divert-to, ipfw fwd, ipfilter rdr\n- OpenBSD: pf rdr-to and divert-to\n- Linux: netfilter REDIRECT and TPROXY\n- Mac OS X: pf rdr and ipfw fwd\n\nSupport for local process information (`-i`) is currently available on Mac OS X\nand FreeBSD.\n\nSSL/TLS features and compatibility greatly depend on the version of OpenSSL\nlinked against. For optimal results, use a recent release of OpenSSL or\nLibreSSL.\n\n\n## Installation\n\nWith the requirements above available, run:\n\n    make\n    make test       # optional unit and e2e tests\n    make sudotest   # optional unit tests requiring privileges\n    make install    # optional install\n\nDependencies are autoconfigured using pkg-config. If dependencies are not\npicked up and fixing `PKG_CONFIG_PATH` does not help, you can specify their\nrespective locations manually by setting `OPENSSL_BASE`, `LIBEVENT_BASE`,\n`LIBPCAP_BASE`, `LIBNET_BASE`, `SQLITE_BASE` and/or `CHECK_BASE` to the \nrespective prefixes.\n\nYou can override the default install prefix (`/usr/local`) by setting `PREFIX`.\nFor more build options and build-time defaults see [`main.mk`](Mk/main.mk)\nand [`defaults.h`](src/defaults.h).\n\n\n## Documentation\n\nSee the manual pages `sslproxy(1)` and `sslproxy.conf(5)` for user\ndocumentation. See [`NEWS.md`](NEWS.md) for release notes listing significant\nchanges between releases and [`SECURITY.md`](SECURITY.md) for information on\nsecurity vulnerability disclosure.\n\n\n## License\n\nSSLproxy is provided under a 2-clause BSD license.\nSSLproxy contains components licensed under the MIT, APSL, and LGPL licenses.\nSee [`LICENSE`](LICENSE), [`LICENSE.contrib`](LICENSE.contrib) and\n[`LICENSE.third`](LICENSE.third) as well as the respective source file headers\nfor details.\n\n\n## Credits\n\nSee [`AUTHORS.md`](AUTHORS.md) for the list of contributors.\n\nSSLproxy was inspired by and has been developed based on [SSLsplit](https://www.roe.ch/SSLsplit) \nby Daniel Roethlisberger.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsonertari%2FSSLproxy","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fsonertari%2FSSLproxy","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsonertari%2FSSLproxy/lists"}