[openssl-users] SSL_CTX_set_cert_verify_callback and certificate access
I'm working on an application using openssl, and I would like to set some things up for verification based upon information in the certificate. Unfortunately, from what I can tell, there is no way to do this. (Maybe it's not a good idea. Not sure.) What I would like to do is pull out some information from the certificate that is being verified, set/modify the verify store based upon that information (basically chose the CA based upon something in the certificate. What I really need is X509_STORE_CTX_get_cert(), but that function does not exist, and there's no way to get ctx->cert from what I can tell. It's not available with SSL_get_peer_certificate at the point where the cert verify call is done. It would also be nice to be able to replace the verify store in the X509_STORE_CTX, or empty it, but I haven't looked too hard at that. More details on what I am trying to do follow, in case you are interested... I am the maintainer for ser2net, a program that allows network connections to connect to serial ports. People have asked for login security, but I refuse to transmit passwords like this over the network in the clear. But, in reality, people are logging in over this interface, and it has bothered me for a while. So, I've been looking at adding security. I have rewritten ser2net to split it into two parts: a library that does general-purpose stream I/O to handle all the connections and the serial ports, and the main handling and configuration. The library (called gensio) is a layered system, so you have TCP/UCP/SCTP/stdio/serial/IPMIsol available as low-level interfaces. Then you have filter layers on top, like SSL and telnet. So you can create an SCTP connection, put SSL on top of that, then put telnet on top of that, for instance. I already have basic SSL support working. My first inclination for a secure connection was to use ssh. However, ssh is not as well suited for this as I would have liked, and all the ssh libraries are tied to a file descriptor in ways that are not easily fixable, and thus can't be used on top of an abstract connection, which is what I need. That was rather disappointing, as it would have been really nice to for users to just be able to ssh to ser2net. So now I'm looking at doing something like what ssh does, but with openssl. Unfortunately, SSL has no concept of a userid and I would like to have it verify certificates from different stores based upon a userid. I've come up with the following options: 1. Send the userid in a lower layer filter so it is transmitted before ssl starts up. This means the userid is not authenticated in any way, which seems like a bad idea. 2. Set the userid in the certificate and use client authentication to authenticate the user logging in. Set the username in the CN field of the certificate so it can't be changed, extract that and set the CA before verification. This is what I'm currently trying to do, and I keep running into roadblocks. 3. Create a filter layer that can sit on top of SSL that will basically do what SSL client authentication does, except it can get the userid as the first part of the data and then run the authentication from there. This is definitely doable, and then the userid is transmitted encrypted (which seems nice) but it's duplicating some fairly complex code that would already be done for me by openssl. I am afraid I am going to be stuck with option 3, which is not terrible, I suppose. But does anyone have any ideas here? Thanks, -corey -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] is there an API to list all the TLS 1.3 cipher suite names?
On Wed 2019-01-09 04:16:05 +, Jordan Brown wrote: > On 1/8/2019 7:44 PM, Viktor Dukhovni wrote: >> You could just provide a free-form emergency string parameter that >> users are advised to not change unless some major advance makes it >> necessary. At that time, advice can be published as to what the >> override setting should be. > > That doesn't sound like a 21st century user interface. a 21st century interface is: upgrade your software to the new patch level that avoids the known flaws. --dkg -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] possible C bugs in ecp_nistp521
> I would expect that correct results would be provided for all valid > inputs (including those inputs that are not otherwise constrained). > As such, I would class this as a bug in OpenSSL. These functions are not part of the public OpenSSL API so that's just not how it works. There is a ton of internal code across the library that makes assumptions about the inputs, e.g. in this case the internal caller using some non-trivial representation that somehow bounds limbs. In this instance, I suspect Patrick's statement is valid -- hopefully it's just a documentation typo and the bounds are tighter. In any case, this (and any other might-be arithmetic bug) is potentially a security issue so it shouldn't be discussed on a public mailing list. BBB -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] is there an API to list all the TLS 1.3 cipher suite names?
On 1/8/2019 8:21 PM, Viktor Dukhovni wrote: > How do you plan to offer a built-in menu of algorithms that have not > yet been added to OpenSSL? I'm a bit confused as to why we would need to - if the underlying OpenSSL doesn't support a particular algorithm, then there's no need to disable it. The ideal would be that we ask OpenSSL what algorithms (and protocol versions) it supports, and we export that list to the user. However, practically we've found that we couldn't do that even with TLS1.2, because (a) "openssl ciphers" (and the underlying APIs) report PSK-* and other algorithms we don't intend to support, and (b) the underlying OpenSSL includes support for algorithms that our security policies don't allow us to support. Also, there's the question of whether a particular algorithm or protocol version is supported but disabled by default, or enabled by default. For instance, today we support TLS 1.0, 1.1, and 1.2, but 1.0 is disabled by default. That's a policy question that OpenSSL can't help us with. > And if users are better off leaving the list alone, why encourage that > with a fancy UI? That's a good question, but at the same time we have a high-level UI policy that we don't offer "non-fancy" UIs. >> However, as I think about it, I remember that we already need a >> softcoded list of algorithms, to avoid offering (e.g.) the PSK >> algorithms. > In TLS 1.3, the handshake parameters are configured separately from > the cipherlist. The use of (non-resumption) PSKs requires callbacks, > so they're never enabled out of the box. > >> It sounds like TLS 1.3 will need the same. > Actually, it won't, nor did earlier versions, the ciphers were > listed by "openssl ciphers -v", but they can't get activated without > application support. Right... we found that when we blindly asked for the cipher list, it included ciphers that weren't actually operable because we didn't have the associated application support. We had hoped to be able to use relatively simple rules to determine the list of allowable ciphers, but then found that we needed much more complex rules than were desirable. -- Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
