[issue31242] Add SSLContext.set_verify_callback()
Change by Kent Watsen : -- nosy: +kwatsen ___ Python tracker <https://bugs.python.org/issue31242> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31242] Add SSLContext.set_verify_callback()
Kent Watsen added the comment: Very much needing this! My situation is a mutli-tenant asynchio-based server whereby each tenant is able to configure other clients that can connect. The current strategy requires all certs to be known up-front that, for now, necessitates a painful restart whenever new auth for a client-certificate is configured. -- ___ Python tracker <https://bugs.python.org/issue31242> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18233] SSLSocket.getpeercertchain()
Kent Watsen added the comment: I don't understand the concern issues being raised for this patch, and also may have a use-case not mentioned yet. For the concern issue, as I understand it, the ability to call getpeercert() or the proposed getpeercertchain() is only after the TLS session has been established. As such, the SSL socket already established that there exists a valid chain of trust. Thus these methods are primarily to provide visibility into what the peer passed *after* it had been authenticated, right? That said, the reason I want to access the entire certificate chain passed by the client (i.e., client cert auth) is in order to validate that the client's cert (which may include some intermediates) authenticates to a specific trust anchor, rather than the bag of trust anchors loaded into the SSLContext (via load_verify_locations()) in order to authenticate a multiplicity of clients, each potentially leading to a different trust anchor. Not having getpeercertchain() means that all no client cert may contain a chain, i.e., the clients only ever transmit the end-entity cert itself. This is unfortunate because the underlying SSL socket actually allows clients to send chains, it's just the lack being able to access the peercertchain in my code that seems to limit the solution. -- nosy: +kwatsen ___ Python tracker <https://bugs.python.org/issue18233> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18233] SSLSocket.getpeercertchain()
Kent Watsen added the comment: It seems that we're talking about the same thing, but I want the cert-chain the peer sent without any smarts, exactly how OpenSSL's SSL_get_peer_cert_chain() works and, importantly, without stapling any root chain certs the client did not send itself (though it's okay if the client did, in which case those certs should be included). I'm not following your "I pass the chain [A, leaf cert]" comment, if leaf-cert is signed by B, then this should obviously fail. Maybe you meant to say that A and B are loaded into a bag and that validation test is [bag, leaf-cert]? Regardless, I don't think Python should coddle developers. Assuming the docs are accurate, competent developers with crypto-clue will be fine. Many crypto library docs encourage tourists to stay away. That said, if smarts are wanted, let's choose a name that doesn't overlap with the existing OpenSSL name...get_authed_cert_chain() ? But, please, can a "peer_cert_chain()" wrapping the OpenSSL call be release ASAP, buying time to ponder the merits of smart calls for another day? -- ___ Python tracker <https://bugs.python.org/issue18233> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18233] SSLSocket.getpeercertchain()
Kent Watsen added the comment: I agree that having both would be best, but there is a world of difference between a must-have (peer_cert_chain) and what seems to be a nice-to-have (authed_peer_cert_chain). My request for clarification was not that I don't understand bags, etc. (see my first message), but that I don't understand the concrete use case in mind. That is, when is it that the app-logic would differ because the EE cert validated using one path versus another? To explain the 'must-have' better, imagine one peer sending [A, B, C], where 'A' is the EE cert, and the other peer having TA [F, E, D], where 'F' is the self-signed root TA and 'D' is the Issuer that signed 'C'. The complete chain is [A-F] and this is what the SSL-level code will use during the handshake. But post-handshake, without peer_chain_cert(), there is NO WAY for the app-logic to create a valid chain. This is broken, for the reason mentioned in my first message. -- ___ Python tracker <https://bugs.python.org/issue18233> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42628] binascii doesn't work on some base64
New submission from Kent Watsen :
[Tested on 3.8.2 and 3.9.0, bug may manifest in other versions too]
The IETF sometimes uses the dummy base64 value "base64encodedvalue==" in
specifications in lieu of a block of otherwise meaningless b64.
Even though it is a dummy value, the value should be convertible to binary and
back again. This works using the built-in command `base64` as well as OpenSSL
command line, but binascii is unable to do it. See below:
$ echo "base64encodedvalue==" | base64 | base64 -d
base64encodedvalue==
$ echo "base64encodedvalue==" | openssl enc -base64 -A | openssl enc -d base64
-A
base64encodedvalue==
$ printf "import
binascii\nprint(binascii.b2a_base64(binascii.a2b_base64('base64encodedvalue=='),
newline=False).decode('ascii'))" | python -
base64encodedvaluQ==
After some investigation, it appears that almost any valid base64 matching the
pattern "??==" fails. For instance:
$ printf "import
binascii\nprint(binascii.b2a_base64(binascii.a2b_base64('ue=='),
newline=False).decode('ascii'))" | python -
uQ==
$ printf "import
binascii\nprint(binascii.b2a_base64(binascii.a2b_base64('aa=='),
newline=False).decode('ascii'))" | python -
aQ==
$ printf "import
binascii\nprint(binascii.b2a_base64(binascii.a2b_base64('a0=='),
newline=False).decode('ascii'))" | python -
aw==
Is this a bug?
--
messages: 382922
nosy: kwatsen2
priority: normal
severity: normal
status: open
title: binascii doesn't work on some base64
type: behavior
versions: Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue42628>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42628] binascii doesn't work on some base64
Kent Watsen added the comment: No activity in 3 weeks. Selecting a couple components to give it a bump. -- components: +C API, Library (Lib) nosy: +kwatsen ___ Python tracker <https://bugs.python.org/issue42628> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42628] binascii doesn't work on some base64
Change by Kent Watsen : -- nosy: -kwatsen2 ___ Python tracker <https://bugs.python.org/issue42628> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42628] binascii doesn't work on some base64
Kent Watsen added the comment: I see. There are two issues: 1) my `base64` and `openssl` CLI commands were flipped, as you point out, giving a false positive - oops ;) 2) more importantly, the base64 value "ue==" is invalid (there is no binary input that could possibly generate it) and none of the implementations issued a warning or error, which is reasonable IMO. Thank you for your help. Please close this issue. -- ___ Python tracker <https://bugs.python.org/issue42628> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
