[libmicrohttpd] problem in client certificate authentication example?
Hi,
(I've sent an e-mail about this possible problem to the maintainer
as well)
https://www.gnu.org/software/libmicrohttpd/tutorial.html#Adding-a-layer-of-security
shows an example for performing client certificate authentication.
The function get_client_certificate invokes
gnutls_certificate_verify_peers2 to verify the validness of the
certificate.
That gnutls_certificate_verify_peers2 function returns a result code but
also a status-code. According to
https://www.gnutls.org/manual/html_node/Core-TLS-API.html the result
code only tells you whether the evaluation itself went well, not if the
certificate is valid. For that second part, one would need to evaluate
the second parameter ("unsigned int * status") which contains the status
of the certificate, see
https://www.gnu.org/software/gnutls/reference/gnutls-gnutls.html#gnutls-certificate-status-t
So only if that status (client_cert_status in the example) is 0, the
certificate should be used.
In my opinion the example should be changed to verify that status as
people may use the example "as is", potentially implementing
security-problems in software using it.
Hopefully I'm wrong in my analysis!
Regards,
Folkert van Heusden
--
Always wondered what the latency of your webserver is? Or how much more
latency you get when you go through a proxy server/tor? The numbers
tell the tale and with HTTPing you know them!
http://www.vanheusden.com/httping/
[libmicrohttpd] doing "client certificate authentication" earlier in the TLS handshake
Hi, In the client certificate authentication example at https://www.gnu.org/software/libmicrohttpd/tutorial.html#Adding-a-layer-of-security the check seems to be performed after tls session setup. I deduced that from: ci = MHD_get_connection_info (connection, MHD_CONNECTION_INFO_GNUTLS_SESSION); tls_session = ci->tls_session; I think it would be better to do this verification during the TLS handshake (I don't know if there is such a thing!) for safety reasons. My question now is: can this be realised with libmicrohttpd? Maybe via a callback, maybe going through libmicrohttpd all the way into gnutls? Regards, Folkert van Heusden --
[libmicrohttpd] why
Hi, While going through the libmicrohttpd sources, I noticed this part in daemon.c: /* Allocate memory pool in the processing thread so * intensively used memory area is allocated in "good" * (for the thread) memory region. It is important with * NUMA and/or complex cache hierarchy. */ connection->pool = MHD_pool_create (daemon->pool_size); I'm curious why libmicrohttpd is doing its own memory management. If I remember correctyl the memory allocater of glibc has pools of memory per thread? It does keep freed() memory in a per-thread list before it is moved to the global pool of free memory. Regards.
[libmicrohttpd] chunked encoding & mjpeg stream
Hello,
Some browsers (like chrome and firefox) get confused when showing an
mjpeg-stream when produced by libmicrohttpd. Most likely this is caused
by the chunked encoding.
An MJPEG stream consists of a "multipart/x-mixed-replace" http-stream of
jpeg images. After every jpeg frame, a multipart-header is added -
regular ascii with \r\n.
E.g.:
\r\n
--myboundary123\r\n
Content-Type: image/jpeg\r\n
Content-Length: 1234\r\n
\r\n
[... data ...]
Chunked encoding adds some data to it:
[pid 27739] sendto(7, "3A74\r\n\r\n--12345\r\nContent-Type:
image/jpeg\r\nContent-Length: 83519\r\n\r\n\
and because of that, the browser often displays no video-frames at all
or only partially.
If I use a http-server which does not produce chunked encoding, things
work fine.
I would like to suggest to add a switch of some sort to disable chunked
encoding. I don't believe it is neccessary for things like mjpeg as the
size of each segment is already included ("Content-Length: 83519\r\n") in
multipart-scheme.
Regards
