[Core] Custom/Modified SSLContext

[jose-pr]

Is your feature request related to a problem? Please describe.
Want to be able to use a modified ssl context that would allow me to use Windows CAPI , or some other engine for client certificate authentication.

Describe the solution you'd like
Something similar to methods available for urllib3 with pyopenssl where the default context can be overridden.

    pyopenssl.inject_into_urllib3()

Describe alternatives you've considered
Using Urllib3 and/or simple socket with a custom SSLContext

ffi = cffi.FFI()
ffi.cdef("int SSL_CTX_set_client_cert_engine(void *ctx, void *e);")
libssl = ffi.dlopen("libssl-1_1.dll")


def set_client_cert_engine(self:PyOpenSSLContext, engine:VoidType):
    if not libssl.SSL_CTX_set_client_cert_engine(self._ctx._context, engine):
        raise Exception("Was not able to set client cert engine")

PyOpenSSLContext.set_client_cert_engine  = set_client_cert_engine

def load_dynamic_engine(so_path:str):
    if not so_path:
        raise ValueError('SO_PATH for engine not provided')

    if isinstance(so_path, str):
        so_path = so_path.encode('utf-8')

    _lib.ENGINE_load_builtin_engines()
    engine = _lib.ENGINE_by_id(b"dynamic")

    if engine == _ffi.NULL:
        raise ValueError('Could not find dynamic engine')

    if not _lib.ENGINE_ctrl_cmd_string(engine,  b"SO_PATH", so_path, 0):
        raise Exception('Error with engine SO_PATH command: {}'.format(
            so_path.decode('utf-8')))

    if not _lib.ENGINE_ctrl_cmd_string(engine,  b"LOAD", _ffi.NULL, 0):
        raise Exception('Error with engine load commad: {}'.format(
            so_path.decode('utf-8')))

    if not _lib.ENGINE_init(engine):
        _lib.ENGINE_free(engine)
        raise Exception('Cannot initialize engine {}'.format(
            so_path.decode('utf-8')))
    return engine
    
def get_default_chain():
    _ctx = ssl.create_default_context()
    return [ crypto.load_certificate(crypto.FILETYPE_ASN1, cert) for cert in _ctx.get_ca_certs(True)]

ca_certs=get_default_chain()
capipath = os.path.join("C:\\", "Program Files", "OpenSSL-Win64", "bin", "capi.dll")

capi = load_dynamic_engine(capipath)

class WindowsSSLContext(pyopenssl.PyOpenSSLContext):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        _ctx=self._ctx
        _ctx.set_options(ssl.OP_NO_TLSv1_1)
        store=_ctx.get_cert_store()
        for cert in ca_certs:
            store.add_cert(cert)
        self.set_client_cert_engine(capi)

def inject_capi_into_urllib3():
    pyopenssl.inject_into_urllib3()
    if urllib3.util.IS_PYOPENSSL:
        urllib3.util.SSLContext = WindowsSSLContext
        urllib3.util.ssl_.SSLContext = WindowsSSLContext

inject_capi_into_urllib3()
        
s = requests.Session()


pki_host=("pki-host" , 9443)

#URLLIB3 
r = s.get("https://%s:%s"%pki_host)
print(r.text)

#Simple Socket with context
ctx = WindowsSSLContext(ssl.PROTOCOL_TLS)
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(pki_host)
s = ctx.wrap_socket(s)

s.sendall("CONNECT %s:%s HTTP/1.0\r\nConnection: close\r\n\r\n"%pki_host)

print(s.recv(4096).decode())       
        

Additional context
Add any other context or screenshots about the feature request here.

[abhinavsingh]

@jose-pr Thank you for opening this. I believe this should be doable. Best way would be to expose another callback to plugins where they can do the SSL negotiation, overriding the default Context used by proxy.py core. Within the callback, plugin authors will be able to utilize pyopenssl or other mechanism as necessary.

I am inclining towards a plugin callback solution (vs flag based) because requirements here are so varied. E.g. in #536 folks want to use custom certs for validation. A callback based solution will help everyone needing custom SSL context. Wdyt?

[jose-pr]

@jose-pr Thank you for opening this. I believe this should be doable. Best way would be to expose another callback to plugins where they can do the SSL negotiation, overriding the default Context used by proxy.py core. Within the callback, plugin authors will be able to utilize pyopenssl or other mechanism as necessary.

I am inclining towards a plugin callback solution (vs flag based) because requirements here are so varied. E.g. in #536 folks want to use custom certs for validation. A callback based solution will help everyone needing custom SSL context. Wdyt?

That would be great, as long as it exposed the base context and allow low level functions on its setup.
Settings TLS options, add cert chain to verify path , ...