[EMAIL PROTECTED] wrote:
Hi,
HASH_* APIs provide a good wrapper for the hashing algorithms.
But secsign.c does not use any of these. It instead calls
create/update/end directly on the hash context.
Would it be better to use HASH_* APIs in secsign.c?
We could use HASH_* APIs in secsign.c. Per
Honzab,
Honzab wrote:
Julien Pierre napsal:
NSS only supports RSA ECDHE cipher suites on the client side at this
time, so this is expected. If you are using NSS on the server side, you
need to enable alternate cipher suites - and of course you need to
enable them on the client side as well.
Hi,
HASH_* APIs provide a good wrapper for the hashing algorithms.
But secsign.c does not use any of these. It instead calls
create/update/end directly on the hash context.
Would it be better to use HASH_* APIs in secsign.c?
Wei
___
dev-tech-crypto
Julien Pierre napsal:
>
> NSS only supports RSA ECDHE cipher suites on the client side at this
> time, so this is expected. If you are using NSS on the server side, you
> need to enable alternate cipher suites - and of course you need to
> enable them on the client side as well.
Thanks for advise
Honzab wrote:
What is strange, that the cipher suite sent from the server is c014 -
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA. This suite is disabled on the
server.
The client socket gets to state with error SSL_ERROR_NO_CYPHER_OVERLAP
and send to the server our SSL_ERROR_HANDSHAKE_FAILURE_ALERT alert
Hi all, I would like to ask for advise.
We are building a firefox extension and we are using our own
implementation of SSL server and client implemented closely to the ssl
sample (security\nss\cmd\SSLsample). We are not using PSM socket
provider implementation.
All certificates (CAs and client/se
6 matches
Mail list logo