I read:
https://datatracker.ietf.org/doc/html/rfc5116#section-3.2
And it says The Counter fields of successive nonces form a monotonically increasing sequence, when those fields are regarded as unsigned integers in network byte order.
But our implementation is currently in host endian (in protocol.c), it only works well in big-endian platform, when counter is more than or equals to 1.
My reading was wrong; Indeed we use memcpy from out_ctr. But it increments in network byte order.
So, for AES-GCM, it works well.
Potentially, we would need a fix, though (for the semantics of out_ctr).
At least, we need to update this logic when we support TLS 1.3, which uses XORed counter and nonce.
In TLS 1.2, it refers RFC5116. In RFC5116, it says:
The Counter part SHOULD be equal to zero for the first nonce, and increment by one for each successive nonce that is generated.
So, current code is fine.