Greetings,

Submitted patch is tested by hands:

$ openssl s_client -connect {h2o_ipaddr:h2o_port}
Pressing R to trigger renegotiation

Patched version does renegotiation properly
while original version is failed as follows:
139675521959584:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:598:

Best regards,
Chul-Woong

Interesting!

However, to make it always work, you must check if there is any write in flight before calling do_write. The socket structure of H2O is not designed to have more than one write request in flight at once.

Can you look into resolving the issue?

Also, it would be great if you could provide how you are going to use the renegotiation. H2O does not provide an interface to obtain the client certificate (or an interface to initiate renegotiation). Are you using libh2o as an event loop?

First commit should always work in handling renegotiation case.
Renegotiation attempt while another write request in flight is ignored in
proposed implementation safely by following reason.

Let's think of situation that peer A receives renegotiation request from peer B.
Proposed implementation adds renegotiation payload onto output.
When there is write operation (let' say it FOO) in flight, the added renego payload are
appended to tail of previous output buffer and removed at on_write_complete()
without actually sending to peer B.
However, B initiated renegotiation but B received FOO, not handshake message.
So B abort the session and A gets notified.
This is a normal consequence.
Proper SSL peers should begin renegotiation only when there is no payload in transit.
In other words, renegotiation breaks in full-duplex data transmission state and should be
attempted in half-duplex state.

But I can think of following imaginary scenario:

1. A send payload [FOO].
   [FOO] is on the wire, but A's event loop are delayed and on_write_complete() does not called
2. B receives [FOO]
3. B sends renegotiation request [HELLO-REQ]
4. A receives [HELLO-REQ]
5. A puts [CLI-HELLO] onto output
6. A's on_write_complete() is called and [CLI-HELO] is discarded.
   • A waits for B's [SVR-HELLO] and
   • B wait for A's [CLI-HELLO]

It's not likely that [FOO]'s completion function to be delayed so much, but it can be possible.
So I submit another commit. I would be grateful if you look into it.

Yes, I'm reading and tinkering with some parts of you code. I like your approach of timer handling in event loop. Iibh2o is already too big to use it as a whole to me.

Thank you for the fix. The code looks fine to me.

My understanding is that your fix has actual value, since client-initiated renegotiation may occur while server is sending data.

Do you have any proposal for exposing renegotiation layer to libh2o and the standalone server?

At least we should have the following:

• API to request renegotiation to h2o_socket_t
• API to obtain client certificate (and related info) from h2o_socket_t
• define configuration directives and implement them

I can work for them, but I would appreciate it if you could come up with a PR.

Thanks for a review.

Supporting client authentication feature on h2o requires some work and
I'm not sure I'm the right person on that work.
I'll pay an attention to it when i'm ready.
It's busy season near year-end. :-)

Regards,
Chul-Woong

My pleasure.

Supporting client authentication feature on h2o requires some work and
I'm not sure I'm the right person on that work.
I'll pay an attention to it when i'm ready.
It's busy season near year-end. :-)

I understand. Thank you for your help anyways in providing the PR. I believe your contribution will help us implementing client authentication to h2o.

Client certificate authentication is widely used in eGovernment and online banking services in Europe. Implementing this feature will allow using h2o in such environments.