On Aug 20, 2014, at 5:33 AM, Igor Galić <i.ga...@brainsware.org> wrote:
> > > ----- Original Message ----- >> James, >> >> Thanks for the feedback. I think Alan already addressed most of the >> issues. Here are my comments on the remaining items. >> >> >>> >>> Why do TSSslCertFindByName() and TSSslCertFindByAddress() take a TSSslVConn >>> argument? >> >> I'm using the TSSslVConn to cache a pointer to the global cert table >> (loaded from ssl_multicert.config). Since in theory the >> ssl_multicert.config could be reloaded at any point, we acquire() a copy > > does this mean we would now support reloading of the ssl config w/o restart? that's been supported for a coupe of years now > > [snip] >>> >>> IIRC, OpenSSL doesn't guarantee anything about the SNI name except that is >>> is a bag of bytes. Is it OK for TSSslVConnServernameGet() to present that >>> as a C string? >> The servername is not null terminated in the packet, but OpenSSL does >> null terminate it before handing back the value via >> SSL_get_servername(). I went back through the openssl to verify the >> null termination. Interestingly some data structures in there are >> storing the servername as buffer plus length, but the one returned is >> NULL terminated and data only. Internally they are doing many strlen >> and strcmp operations on it. > > my recommendation for reading openssl code is to read libressl's version. > > [snip] > > -- i > Igor Galić > > Tel: +43 (0) 664 886 22 883 > Mail: i.ga...@brainsware.org > URL: http://brainsware.org/ > GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641 >
