On 21/12/2018 00:02, Viktor Dukhovni wrote: >> Thanks for the hint. You are correct, and a clear before that set >> of crypto operations gets me a far more reasonable message. > > Makes sense. > >> The error seems to be left around after SSL_accept(), and yet >> it does not appear in my SNI callback. Worse, my verify callback >> (which I was expected to appear) does not seem to be being called. >> Yet the SSL_accept() succeeded. >> >> Any ideas on that? > > 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. This, I suppose, explains the server-side verify callback never being called. 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?). Presumably the ALL has added aNULL ciphers back in, after the weird aNULL:-aNULL sequence (what might be the reason for that?), 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). 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. Is there some way of putting anon suites later in priority? Would :+aNULL after the ALL but before strength-sort be preferred? It does seem to do the right thing in the client hello. [ I do wish that OpenSSL had a settable debug level, the way that GnuTLS does, for showing internal operations such as suite-selection ] > 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. -- Cheers, Jeremy -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
