On Fri, Dec 21, 2018 at 02:24:18PM +0000, Jeremy Harris wrote: > > You provide much too little detail. This particular "error" > > happens when a TLS 1.2 ciphersuite does not correspond to any > > any public key type for which OpenSSL might have a certificate. > > A packet capture showed me the server side picking an aNULL ciphersuite. Which naturally does not map to any kind of certificate. While TLS 1.2 still lives and is still capable of aNULL ciphersuites, it might make sense to add a line of code to detect that condition, and not push anything onto the error stack... > This, I suppose, explains the server-side verify callback never > being called. That callback is about client certificates, but in TLS 1.2 and earlier, it is IIRC not valid to ask for client certificates when there is no server certificate. > The SSL_CTX_set_cipher_list() on both ends was > > aNULL:-aNULL:ALL:+RC4:!LOW:!EXPORT:!MD5:!aDSS:!kECDH:!kDH:!SEED:!IDEA:!RC2:!RC6:@STRENGTH > > (which I think was your suggestion from a while back?). Yes, for pure opportunistic TLS modes for Postfix, when neither side does anything with certificates. > Presumably the ALL has added aNULL ciphers back in, after the weird > aNULL:-aNULL sequence (what might be the reason for that?), IIRC, this is documented somehere. The most recentlky removed ciphers end up at the top of the "stack", and are therefore the most preferred when they are brought back. Therefore, aNULL:-aNULL:ALL produces a list in which the aNULL ciphers are preferred to all others. > and the strength-sorting managed to put many anon ciphers before > authenticating ones (I can see that in the suites list in the client hello). Yes, it is a "stable" sort. > Appending another :!aNULL on the client brings sanity back; the server > gets a verify callback and an ocsp callback, and this leftover error is > not left in the stack. If that's what you want, just use "DEFAULT:..." rather than "aNULL:-aNULL:ALL:...". > Is there some way of putting anon suites later in priority? Note, they're only used when the client enables them, i.e. the client has no intention of authenticating the server? Is there any point in using certificates at that point? That said, it does not sound like you want to support them at all, but if you do, then just "ALL" will leave them at a lower priority than "aRSA" and "aECDSA". > Would :+aNULL > after the ALL but before strength-sort be preferred? It does seem to do > the right thing in the client hello. You might do that, but I don't know of any clients that support *only* aNULL ciphers, so there's not much point in having them at all, if they're not preferred. > > Before beginning a new high-level operation in the SSL library it > > is good to (at least periodically) clear the error stack. Like > > "errno" it is not cleared on function entry, and persists until > > simply cleared or iteratively consumed for reporting. > > It's rather awkward that one doesn't know exactly what such a clear > might be required. Randomly spraying them around is hardly nice. > The comparison with errno is poor; there, if the syscall failed > you know that errno is valid. Here, if the library call fails > you know only that one-or-more of the stack are valid, but not > always the ones first accessible from the stack. > > I guess for now I'll put a clear after SSL_accept succeeds, and hope > that suffices. In Postfix we strive to clear the error stack before each high level operation that reports errors on failure. That way we're only reporting the relevant errors. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
