On Fri, Sep 02, 2022 at 12:22:35AM +, Wall, Stephen wrote:
> > A compromised server could easily still request the client certificate, no?
>
> > But as noted, even a compromised server can ask for client credentials and
> > then
>
> Yes, that's true. If the intruder knew to do so. Also,
> A compromised server could easily still request the client certificate, no?
> But as noted, even a compromised server can ask for client credentials and
> then
Yes, that's true. If the intruder knew to do so. Also, a thief can break your
window and get into your car, so you might as well
> > It is not clear what threat model warrants taking special action when
> > the client certificate is not requested. It could equally be
> > requested and then largely ignored.
>
> A client in a highly secured network knows that every server it connects to
> will
> require a client
> It is not clear what threat model warrants taking special action when the
> client
> certificate is not requested. It could equally be requested and then largely
> ignored.
A client in a highly secured network knows that every server it connects to
will require a client certificate. If the
On Thu, Sep 01, 2022 at 09:36:36PM +, Wall, Stephen wrote:
> Does OpenSSL 3.0 provide a way for client side software to verify that
> the server actually sent a request for the client’s certificate?
It is not clear what threat model warrants taking special action when
the client certificate
Does OpenSSL 3.0 provide a way for client side software to verify that the
server actually sent a request for the client’s certificate? As I recall, the
only way to do this in 1.0.2 was to hook in a callback that examined every
handshake message and set a flag if the client cert request was
On Thu, Sep 01, 2022 at 08:21:21AM -0400, Dave Coombs via openssl-users wrote:
> These are the 2 invalid encodings I have seen:
>
> First, a bit-string used for flags, encoded as (hex) 030108. That is,
> the number of unused bits is set to 8, and no other content, presumably
> indicating no
On 01/09/2022 18:15, Matt Caswell wrote:
On 01/09/2022 13:21, Dave Coombs via openssl-users wrote:
So! Is it possible to work around these, using ASN1_MACRO trickery or
what-have-you? It's pretty clear I should end up with an empty bit-
string and integer value 0x42, so is there a way to
On 01/09/2022 16:41, Short, Todd via openssl-users wrote:
OpenSSL 1.1.1 full support expires on 2022-09-11; it then enters
security-fix-only mode until 2023-09-11.
Are there any plans for a final bug-fix release of 1.1.1 in the next
couple weeks (and hopefully a 3.0 release as well)?
On 01/09/2022 13:21, Dave Coombs via openssl-users wrote:
So! Is it possible to work around these, using ASN1_MACRO trickery or
what-have-you? It's pretty clear I should end up with an empty bit-
string and integer value 0x42, so is there a way to loosen the parser's
pickiness and achieve
OpenSSL 1.1.1 full support expires on 2022-09-11; it then enters
security-fix-only mode until 2023-09-11.
Are there any plans for a final bug-fix release of 1.1.1 in the next couple
weeks (and hopefully a 3.0 release as well)?
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by
Hello,
I have in my possession some smartcards whose pkcs15 objects contain
incorrectly structured DER encodings, and I need to get these cards
working in my card management tool. I've made structs corresponding to
the relevant parts of pkcs15 using openssl's ASN1 module, but naturally
the
12 matches
Mail list logo
