SSL connection with client certificate authentication
530 views
Skip to first unread message
Roman Bednarek
Sep 30, 2015, 9:11:00 AM9/30/15
to civetweb
Hello
I am considering using civetweb in my development project, as, it is easy to embed and use.
The only missing feature which is necessary for my project is authenticating client connections with SSL certificate.
Do you have any plans of supporting such feature in civetweb in near future? I also may try to add it myself to the server, if I will manage to do that..
Thanks for any info
Roman
bel
Oct 13, 2015, 5:41:08 PM10/13/15
to civetweb
Sorry, I thought I already wrote an answer, but it seems it got lost somewhere.
Currently CivetWeb works as typical for a webserver:
There is a SSL server certificate, and the client can check it and then accept data or reject the connection.
This is how a browser typically does.
The Civetweb API also offers client functionality - this currently does not check the certificate.
(1) This is something I plan to add some time later.
Or do you mean an SSL client certificate, to be checked by the server?
This would be an alternative to logging in with a password. The client could still be a browser - if/how a certificate can be installed depends on the browser.
(2) This needs to be checked by the server. So the server would need something like a trusted client certificate list.
(3) It is also possible to extend the CivetWeb Client C API to send a client certificate, which should be checked by the server.
Which one - (1), (2) or (3) - you need depends on the use case. Should this be an alternative to authenticating with a password from a browser? Or is it used in a machine-machine communication with both civetweb server and client API?
Currently CivetWeb works as typical for a webserver:
There is a SSL server certificate, and the client can check it and then accept data or reject the connection.
This is how a browser typically does.
The Civetweb API also offers client functionality - this currently does not check the certificate.
(1) This is something I plan to add some time later.
Or do you mean an SSL client certificate, to be checked by the server?
This would be an alternative to logging in with a password. The client could still be a browser - if/how a certificate can be installed depends on the browser.
(2) This needs to be checked by the server. So the server would need something like a trusted client certificate list.
(3) It is also possible to extend the CivetWeb Client C API to send a client certificate, which should be checked by the server.
Which one - (1), (2) or (3) - you need depends on the use case. Should this be an alternative to authenticating with a password from a browser? Or is it used in a machine-machine communication with both civetweb server and client API?
Roman Bednarek
Oct 19, 2015, 6:26:17 AM10/19/15
to civetweb
Hi
I need the server to be able to allow only connections from certified clients.
It is option (2) in your reply, a server needs a file with trusted certificates, and verify connecting clients.
In my case it is machine-machine communication with civetweb only on server side.
I guess that feature may also be used to allow only connections from know browsers in local intranet.
Is there chance you can add such support?
Roman
I need the server to be able to allow only connections from certified clients.
It is option (2) in your reply, a server needs a file with trusted certificates, and verify connecting clients.
In my case it is machine-machine communication with civetweb only on server side.
I guess that feature may also be used to allow only connections from know browsers in local intranet.
Is there chance you can add such support?
Roman
Roman Bednarek
Oct 29, 2015, 8:56:25 AM10/29/15
to civetweb
Hi
I have a close deadline for current project, so we have created an implementation to support verifying client certificate.
It is available at github, https://github.com/MGralka/civetweb/tree/ssl_client.
You can merge it into mainline trunk, if you find it acceptable.
Roman
I have a close deadline for current project, so we have created an implementation to support verifying client certificate.
It is available at github, https://github.com/MGralka/civetweb/tree/ssl_client.
You can merge it into mainline trunk, if you find it acceptable.
Roman
bel
Oct 29, 2015, 6:50:43 PM10/29/15
to civetweb
Again, it seems my answer got lost somewhere:
I already have a prototype implementation, but it is not completely ready for production.
... but now you already have a your code, and I would like to merge it with the mainline (which is under the MIT license).
I already have a prototype implementation, but it is not completely ready for production.
... but now you already have a your code, and I would like to merge it with the mainline (which is under the MIT license).
Roman Bednarek
Oct 30, 2015, 4:45:08 AM10/30/15
to civetweb
Bad luck with communication :(
We could wait a week or two, if I knew you are working on it ...
code in our branch is added with the same license
bel
Oct 30, 2015, 5:55:45 AM10/30/15
to civetweb
I get all posts to the civetweb group to my gmail account, where I can reply by mail.
This used to work some months ago, but - I just tested it - not it seems such comments get lost, and only comments I post directly to the google group are shown.
Maybe the mail reply now gets to the mail address you used to sign up for the group (which is different to some time ago). Maybe it gets lost in digital nirvana.
Anyway:
This used to work some months ago, but - I just tested it - not it seems such comments get lost, and only comments I post directly to the google group are shown.
Maybe the mail reply now gets to the mail address you used to sign up for the group (which is different to some time ago). Maybe it gets lost in digital nirvana.
Anyway:
I already merged it, and started with integrating my previous but incomplete work.
It will take a couple of days until everything is settled.
Thank you for your contribution.
I would also add you to the CREDITS.md file, but I saw the name used in the commits is different to your name here. Any specific wish what you want in this file? I could also add both, or just a nickname or even a company name.
I think I will rename some of the parameters, and get it running for both, openSSL loaded dynamically at runtime (like you did) and openSSL loaded "classically" by including it as a header adding it as dependency.
It will take a couple of days until everything is settled.
Thank you for your contribution.
I would also add you to the CREDITS.md file, but I saw the name used in the commits is different to your name here. Any specific wish what you want in this file? I could also add both, or just a nickname or even a company name.
I think I will rename some of the parameters, and get it running for both, openSSL loaded dynamically at runtime (like you did) and openSSL loaded "classically" by including it as a header adding it as dependency.
Roman Bednarek
Oct 30, 2015, 8:10:43 AM10/30/15
to civetweb
Yes, I have seen your first reply in my google email now, but I do not read it frequently.
It is my team member, he wrote the code, you can add his name to credits.
It is my team member, he wrote the code, you can add his name to credits.
bel
Oct 30, 2015, 4:38:04 PM10/30/15
to civetweb
I will add the name later - I did not update CREDITS.md for some time now, but names don't get lost in the github history anyway - but I will certainly do it before the next release.
I found a problem with your implementation, which I have in my test implementation as well:
Start the server certificate and ask for a client certificate:
Then connect with FireFox, configure it to use the client certificate (resources/cert/client.pem + .key -> .pfx), connect and accept the server certificate (add a firefox security exception for the self-signed server certificate).
This will work the first time - FireFox will show the first page. Then try to open another page on the same server - it will not work but show some security error. If you restart the server, then this second page will work, but you can no longer switch back to the first one. So you can show exactly one page (any page will work), but you can not show a second page (no page will work) - until you restart the server.
I tested it with the server on Windows, the server on Linux, FireFox on Windows and FireFox on Linux, localhost connections, Linux to Windows connections, ... all with the same result: It works just once, then you need to restart the server.
Any idea where the problem could be?
I found a problem with your implementation, which I have in my test implementation as well:
Start the server certificate and ask for a client certificate:
listening_ports 8443s
document_root test
ssl_certificate resources/cert/server.pem
ssl_verify_peer yes
ssl_ca_file resources/cert/client.pem
document_root test
ssl_certificate resources/cert/server.pem
ssl_verify_peer yes
ssl_ca_file resources/cert/client.pem
Then connect with FireFox, configure it to use the client certificate (resources/cert/client.pem + .key -> .pfx), connect and accept the server certificate (add a firefox security exception for the self-signed server certificate).
This will work the first time - FireFox will show the first page. Then try to open another page on the same server - it will not work but show some security error. If you restart the server, then this second page will work, but you can no longer switch back to the first one. So you can show exactly one page (any page will work), but you can not show a second page (no page will work) - until you restart the server.
I tested it with the server on Windows, the server on Linux, FireFox on Windows and FireFox on Linux, localhost connections, Linux to Windows connections, ... all with the same result: It works just once, then you need to restart the server.
Any idea where the problem could be?
Mateusz Gralka
Nov 2, 2015, 11:20:20 AM11/2/15
to civetweb
Hi!
Yeah I've noticed that too. I'll look into it this week. I also plan to implement ssl_default_verify_paths and ssl_forward_secrecy.
Yeah I've noticed that too. I'll look into it this week. I also plan to implement ssl_default_verify_paths and ssl_forward_secrecy.
|
|
|
|
Mateusz Gralka
Nov 4, 2015, 3:33:41 AM11/4/15
to civetweb
After looking at the traffic with ssldump I found what the problem was.
From the documentation at
https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_session_id_context.html:
"If the session id context is not set on an SSL/TLS server and client
certificates are used, stored sessions will not be reused but a fatal
error will be flagged and the handshake will fail."
Which is what seems to be happening in our case - every subsequent call
to SSL_accept fails because browser sends session id it wants to resume
but caching is not enabled on the server side.
Using SSL_CTX_set_session_id_context fixes the problem. I made a branch
with the fix in my repo:
https://github.com/MGralka/civetweb/tree/session_cache_fix
Reply all
Reply to author
Forward
0 new messages