[erlang-questions] New ssl vs Google Chrome

[Per Hedeland]

Ingela Andin <ingela.andin@REDACTED> wrote:
>
>2012/3/7, Per Hedeland <per@REDACTED>:
>>
>> The three calls in public_key:sign/3 add upp to about a millisecond on
>> my slow test system.
>
>Acctually it is  public_key:encrypt_private that will be used as
>signing function for your cipher suite, only the latest version of TLS
>uses public_key:sign for RSA.

Ah, I didn't bother following the code, just grabbed the 'sign'. But
it's essentially the same thing I guess, in any case it takes pretty
much exactly as long to run.

>It would be interesting if you could test how much gain you would get
>on your slow machin if calling crypto:sign or
>crypto:rsa_private_encrypt with the mpint-values directly.

I did that for encrypt_private/rsa_private_encrypt, but there was no
improvement - no surprise really, it's the same mpint calls as in
'sign', where I measured them to take ~ 1 ms total (out of 1400+).

>Old ssl had a bottleneck-process that all connections talked to so
>maybe less parallel processing happened to be beneficial for chromes
>stupidity.

Yes, I suspect it's something like that - "new" is too efficient.:-)
Actually in our case serializing the processing is almost an advantage,
we don't want a connection from chrome to "take over the box". But
having not only seen but actually worked on the innards of ssl_esock, I
certainly don't want it back...

Finding a way to achieve the same "level of non-parallelism" in "new",
i.e. serializing just the processing in the individual steps of the
handshake, should be doable (and possibly useful for low-end systems) I
guess, but I can't quite find my way in the state machine yet.
Serializing the ssl_accept() invocations was trivial but not a good
idea.:-)

>> If you want I can send you ssldump output off-list.
>
>Pleas do.

Coming right up...

Thanks!

--Per