SSL: Getting master_secret and client_random (or premaster_secret)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

SSL: Getting master_secret and client_random (or premaster_secret)

Roger Lipscombe-2
We're using ECDHE and DHE ciphers for our SSL connections. This
provides perfect forward secrecy, which is good, but it makes it
impossible to decipher packet captures in wireshark, which is
expected, and also good, almost all of the time.

Sometimes, however, we *do* need to decipher the traffic.

Note that we own both the client (which is embedded) and the server
(which uses Erlang -- otherwise I wouldn't be asking here -- and
ranch). We *could* offer a different cipher suite on the server, which
would disable PFS, but would do it for all connections. I'd prefer
something a bit more fine-grained.

You can feed a key log to Wireshark, as documented at
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format,
and it'll correctly decipher the traffic for that connection.

I'd like to find a way to generate a key log file. This requires
either (client_random, master_secret) or (encrypted_premaster_secret,
premaster_secret).

Note that I'm looking at the OTP 17.5 source, because that's what we're using.

It would seem that premaster_secret is not stored past the initial
negotiation, but the client_random and master_secret values are in the
#security_parameters record in the #connection_state record in the
#connection_states record, which is in the #state record of the SSL
connection pid.

But I can't see any (clean) way to retrieve these values, in order to
generate a key log suitable for Wireshark.

Is there any clean way to do this in OTP 17.5, or is there a supported
way to do this in OTP 18.x or 19.x?

Regards,
Roger.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL: Getting master_secret and client_random (or premaster_secret)

Roger Lipscombe-2
Further searching shows that Ingela rejected something related in
http://erlang.org/pipermail/erlang-patches/2012-February/002681.html,
but I'm not sure whether that was about exposing the key material or
the way that that patch should have been implemented as ssl:prf (which
it eventually was).

On 5 January 2017 at 14:20, Roger Lipscombe <[hidden email]> wrote:

> We're using ECDHE and DHE ciphers for our SSL connections. This
> provides perfect forward secrecy, which is good, but it makes it
> impossible to decipher packet captures in wireshark, which is
> expected, and also good, almost all of the time.
>
> Sometimes, however, we *do* need to decipher the traffic.
>
> Note that we own both the client (which is embedded) and the server
> (which uses Erlang -- otherwise I wouldn't be asking here -- and
> ranch). We *could* offer a different cipher suite on the server, which
> would disable PFS, but would do it for all connections. I'd prefer
> something a bit more fine-grained.
>
> You can feed a key log to Wireshark, as documented at
> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format,
> and it'll correctly decipher the traffic for that connection.
>
> I'd like to find a way to generate a key log file. This requires
> either (client_random, master_secret) or (encrypted_premaster_secret,
> premaster_secret).
>
> Note that I'm looking at the OTP 17.5 source, because that's what we're using.
>
> It would seem that premaster_secret is not stored past the initial
> negotiation, but the client_random and master_secret values are in the
> #security_parameters record in the #connection_state record in the
> #connection_states record, which is in the #state record of the SSL
> connection pid.
>
> But I can't see any (clean) way to retrieve these values, in order to
> generate a key log suitable for Wireshark.
>
> Is there any clean way to do this in OTP 17.5, or is there a supported
> way to do this in OTP 18.x or 19.x?
>
> Regards,
> Roger.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL: Getting master_secret and client_random (or premaster_secret)

Technion
In reply to this post by Roger Lipscombe-2

Hi,


Is it a solution to for you to deal with it on the client side?


https://jimshaver.net/2015/02/11/decrypting-tls-browser-traffic-with-wireshark-the-easy-way/


Chrome lets you write keys out.




From: [hidden email] <[hidden email]> on behalf of Roger Lipscombe <[hidden email]>
Sent: Friday, 6 January 2017 1:20 AM
To: [hidden email]
Subject: [erlang-questions] SSL: Getting master_secret and client_random (or premaster_secret)
 
We're using ECDHE and DHE ciphers for our SSL connections. This
provides perfect forward secrecy, which is good, but it makes it
impossible to decipher packet captures in wireshark, which is
expected, and also good, almost all of the time.

Sometimes, however, we *do* need to decipher the traffic.

Note that we own both the client (which is embedded) and the server
(which uses Erlang -- otherwise I wouldn't be asking here -- and
ranch). We *could* offer a different cipher suite on the server, which
would disable PFS, but would do it for all connections. I'd prefer
something a bit more fine-grained.

You can feed a key log to Wireshark, as documented at
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format,
developer.mozilla.org
Key logs can be written by NSS so that external programs can decrypt TLS connections. Wireshark 1.6.0 and above can use these log files to decrypt packets.


and it'll correctly decipher the traffic for that connection.

I'd like to find a way to generate a key log file. This requires
either (client_random, master_secret) or (encrypted_premaster_secret,
premaster_secret).

Note that I'm looking at the OTP 17.5 source, because that's what we're using.

It would seem that premaster_secret is not stored past the initial
negotiation, but the client_random and master_secret values are in the
#security_parameters record in the #connection_state record in the
#connection_states record, which is in the #state record of the SSL
connection pid.

But I can't see any (clean) way to retrieve these values, in order to
generate a key log suitable for Wireshark.

Is there any clean way to do this in OTP 17.5, or is there a supported
way to do this in OTP 18.x or 19.x?

Regards,
Roger.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
erlang.org
Mailing list for general discussions about Erlang/OTP, the language, implementation, usage, beginners questions, etc... To see the collection of prior postings to the ...



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL: Getting master_secret and client_random (or premaster_secret)

Ingela Andin
Hi!

There is currently no supported way. ERL-166 https://bugs.erlang.org/browse/ERL-166 talks about the possibility to add such a feature. We have not had time to look further into this as yet.
Of course, it is possible to provide such an API, although it seems to me that the use case is violating the concept of using TLS in the first place. It can, of course, be argued that if you have access to the erlang node you may dig out the information anyway even if it might be a dirty hack. 

Regards Ingela Erlang/OTP team - Ericsson AB
  

2017-01-06 0:13 GMT+01:00 Technion <[hidden email]>:

Hi,


Is it a solution to for you to deal with it on the client side?


https://jimshaver.net/2015/02/11/decrypting-tls-browser-traffic-with-wireshark-the-easy-way/


Chrome lets you write keys out.




From: [hidden email] <[hidden email]> on behalf of Roger Lipscombe <[hidden email]>
Sent: Friday, 6 January 2017 1:20 AM
To: [hidden email]
Subject: [erlang-questions] SSL: Getting master_secret and client_random (or premaster_secret)
 
We're using ECDHE and DHE ciphers for our SSL connections. This
provides perfect forward secrecy, which is good, but it makes it
impossible to decipher packet captures in wireshark, which is
expected, and also good, almost all of the time.

Sometimes, however, we *do* need to decipher the traffic.

Note that we own both the client (which is embedded) and the server
(which uses Erlang -- otherwise I wouldn't be asking here -- and
ranch). We *could* offer a different cipher suite on the server, which
would disable PFS, but would do it for all connections. I'd prefer
something a bit more fine-grained.

You can feed a key log to Wireshark, as documented at
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format,
Key logs can be written by NSS so that external programs can decrypt TLS connections. Wireshark 1.6.0 and above can use these log files to decrypt packets.


and it'll correctly decipher the traffic for that connection.

I'd like to find a way to generate a key log file. This requires
either (client_random, master_secret) or (encrypted_premaster_secret,
premaster_secret).

Note that I'm looking at the OTP 17.5 source, because that's what we're using.

It would seem that premaster_secret is not stored past the initial
negotiation, but the client_random and master_secret values are in the
#security_parameters record in the #connection_state record in the
#connection_states record, which is in the #state record of the SSL
connection pid.

But I can't see any (clean) way to retrieve these values, in order to
generate a key log suitable for Wireshark.

Is there any clean way to do this in OTP 17.5, or is there a supported
way to do this in OTP 18.x or 19.x?

Regards,
Roger.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Mailing list for general discussions about Erlang/OTP, the language, implementation, usage, beginners questions, etc... To see the collection of prior postings to the ...



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL: Getting master_secret and client_random (or premaster_secret)

Kenneth Lakin
On 01/11/2017 11:12 AM, Ingela Andin wrote:
> Of course, it is possible to provide such an API, although it
> seems to me that the use case is violating the concept of using
> TLS in the first place.

AFAICT, TLS protects the data in transit, provides data integrity
guarantees, and provides optional peer authentication. Maybe I'm
poorly-informed, but (because the peers have to perform the TLS
handshaking, encryption, and decryption) it seems that it is assumed
that the peers have access to the master secret, server/client random
and the like.

OpenSSL 1.1.0 appears to expose functions that provide the information
that Lipscomb is looking for:
<https://www.openssl.org/docs/man1.1.0/ssl/SSL_get_client_random.html>

BoringSSL (Google's fork of OpenSSL that reportedly aims to be
conservative and sane) also exposes these functions:
<https://commondatastorage.googleapis.com/chromium-boringssl-docs/ssl.h.html#SSL_get_client_random>
and
<https://commondatastorage.googleapis.com/chromium-boringssl-docs/ssl.h.html#SSL_SESSION_get_master_key>

As to extracting the information of interest in the Erlang ssl library,
The two-argument variant of the ssl:connection_info function looks
promising.

As to implementation, it kinda looks like ssl:connection_info eventually
calls ssl_connection:connection_info. One could take a cue from the code
in ssl_connection:handle_call({prf ...) to extract the
security_parameters from the current connection state, extract
master_secret and client_random from security_parameters, and then add
them to the list that ssl_connection:connection_info returns. It looks
like ssl:connection_info/2 will filter out the things that weren't
requested and pass the rest on to the caller. The one-argument variant
returns {ConnectionProtocol, ConnectionCyphersuite}, regardless of of
any additional information that the called function handed back to it.

It also looks like ssl_handshake has some exported premaster_secret
functions, but I'd need to do a bit of reading to figure out how to make
use of them.



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL: Getting master_secret and client_random (or premaster_secret)

Roger Lipscombe-2
On 11 January 2017 at 21:06, Kenneth Lakin <[hidden email]> wrote:
> As to extracting the information of interest in the Erlang ssl library,
> The two-argument variant of the ssl:connection_info function looks
> promising.

I've not looked at the code, but that sounds like a sensible place to
graft this in, sure.

> It also looks like ssl_handshake has some exported premaster_secret
> functions, but I'd need to do a bit of reading to figure out how to make
> use of them.

I'm not 100% sure, but I believe that the functions in ssl_handshake
are used to generate premaster_secret and, from that, the
master_secret, etc. I only had a cursory glance, though.

Cheers,
Roger.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL: Getting master_secret and client_random (or premaster_secret)

Roger Lipscombe-2
In reply to this post by Ingela Andin
On 11 January 2017 at 19:12, Ingela Andin <[hidden email]> wrote:
There is currently no supported way. ERL-166 https://bugs.erlang.org/browse/ERL-166 talks about the possibility to add such a feature. We have not had time to look further into this as yet.

I'm happy to submit a PR to implement this, provided we can agree on the approach (but it'll be a month or two -- we're still on Erlang 17.x, and there's no point in submitting a patch against that).
 
Of course, it is possible to provide such an API, although it seems to me that the use case is violating the concept of using TLS in the first place. It can, of course, be argued that if you have access to the erlang node you may dig out the information anyway even if it might be a dirty hack. 

I *would* argue that: We own the server, so the unencrypted traffic is already available. All this is doing is making it easier to see that data in wireshark, where there's a bunch of other useful context.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL: Getting master_secret and client_random (or premaster_secret)

Ingela Andin
Hi!

2017-01-12 0:17 GMT+01:00 Roger Lipscombe <[hidden email]>:
On 11 January 2017 at 19:12, Ingela Andin <[hidden email]> wrote:
There is currently no supported way. ERL-166 https://bugs.erlang.org/browse/ERL-166 talks about the possibility to add such a feature. We have not had time to look further into this as yet.

I'm happy to submit a PR to implement this, provided we can agree on the approach (but it'll be a month or two -- we're still on Erlang 17.x, and there's no point in submitting a patch against that).
 
Of course, it is possible to provide such an API, although it seems to me that the use case is violating the concept of using TLS in the first place. It can, of course, be argued that if you have access to the erlang node you may dig out the information anyway even if it might be a dirty hack. 

I *would* argue that: We own the server, so the unencrypted traffic is already available. All this is doing is making it easier to see that data in wireshark, where there's a bunch of other useful context.


Well our reasoning at the moment is that we could add a debug possibility, that would let connection_information (ssl connection_info is deprecated due to its inflexible return value from old ssl).
return client/server/master_secret values for connections started in debug mode. Just like you can configure a connection to run anonymous ciphers suites for test and debugging purposes. However we would
not want connection_information to return these values by default. Even if you conceptually can get at the information by hacking we do not want to make it easy to do bad things to security by "accident" or
otherwise.

Regards Ingela Erlang/OTP team - Ericsson AB
 
 


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL: Getting master_secret and client_random (or premaster_secret)

Roger Lipscombe-2
On 13 January 2017 at 09:39, Ingela Andin <[hidden email]> wrote:
> Well our reasoning at the moment is that we could add a debug possibility,
> that would let connection_information
> return client/server/master_secret values for connections started in debug
> mode. Just like you can configure a connection to run anonymous ciphers
> suites for test and debugging purposes. However we would
> not want connection_information to return these values by default. Even if
> you conceptually can get at the information by hacking we do not want to
> make it easy to do bad things to security by "accident" or
> otherwise.

Sure. There's precedent for that: process_info/1 doesn't return
everything that you can ask for in process_info/2, no?

I'm not sure how this would do bad things to security. The server's
already seeing the plaintext, otherwise it couldn't do its job. Could
you explain your concerns further?
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL: Getting master_secret and client_random (or premaster_secret)

Ingela Andin
Hi!

2017-01-13 11:43 GMT+01:00 Roger Lipscombe <[hidden email]>:
On 13 January 2017 at 09:39, Ingela Andin <[hidden email]> wrote:
> Well our reasoning at the moment is that we could add a debug possibility,
> that would let connection_information
> return client/server/master_secret values for connections started in debug
> mode. Just like you can configure a connection to run anonymous ciphers
> suites for test and debugging purposes. However we would
> not want connection_information to return these values by default. Even if
> you conceptually can get at the information by hacking we do not want to
> make it easy to do bad things to security by "accident" or
> otherwise.

Sure. There's precedent for that: process_info/1 doesn't return
everything that you can ask for in process_info/2, no?

I'm not sure how this would do bad things to security. The server's
already seeing the plaintext, otherwise it couldn't do its job. Could
you explain your concerns further?


As long as it stays on the server....  TLS is suppose to provide peer to peer security
and you are not suppose to be able to read TLS data in traffic sniffing logs.
What if someone decides to transfer the logs in an insecure way from the server!

What if someone thinks its a good idea to decrypt the data outside the TLS connection in the server
and send it to an external logging server in the clear!

 
When it comes to security you should be very careful is all I am saying, and providing a way for others
to use secret information in a not intended way is potentially dangerous.

Regards Ingela Erlang/OTP Team - Ericsson AB








_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL: Getting master_secret and client_random (or premaster_secret)

Kenneth Lakin
In reply to this post by Ingela Andin
On 01/13/2017 01:39 AM, Ingela Andin wrote:
> When it comes to security you should be very careful...

Agreed.

> However we would not want connection_information to return these values
> by default.

That's sensible. master_secret, server_random, and client_random should
be documented options (with a "THIS INFORMATION IS SECURITY SENSITIVE!
BE CAREFUL!" warning attached to them) for ssl:connection_information/2.

However, what does it mean to start a connection in "debug mode"? The
string "debug" neither appears in the ssl module documentation, nor in
its source code (OTP 19.2). Isn't limiting access to those parameters to
an explicit request (via ssl:connection_information/2) a sufficiently
high barrier? Why require one to start a connection in a special mode in
addition to making the explicit request for the parameters?

> What if someone thinks its a good idea to decrypt the data
> outside the TLS connection in the server and send it to an
> external logging server in the clear!

The server already has the plaintext that was transferred through the
TLS tunnel. TLS doesn't protect you from your peer, it protects you from
someone in the middle. :)

> What if someone decides to transfer the logs in an insecure way from
> the server!

Sure, but "malicious or poorly-thought-out TLS peers (or system
operators)" are -AFAICT- outside the scope of the protection that TLS
provides. Given that both OpenSSL and BoringSSL provide functions to
extract client/server random and master secret, it seems that there is a
legitimate (if niche) reason for exposing this information to clients.

I mean, the Erlang ssl module allows you to turn off BEAST mitigation
and the block cypher padding check. These options are arguably more
dangerous than what's being discussed (as they weaken TLS's MITM
protections (leaving you open to POODLE and BEAST)) but they are _very_
useful in certain niche situations.



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL: Getting master_secret and client_random (or premaster_secret)

Ingela Andin
Hi!

2017-01-13 19:16 GMT+01:00 Kenneth Lakin <[hidden email]>:
On 01/13/2017 01:39 AM, Ingela Andin wrote:
> When it comes to security you should be very careful...

Agreed.

> However we would not want connection_information to return these values
> by default.

That's sensible. master_secret, server_random, and client_random should
be documented options (with a "THIS INFORMATION IS SECURITY SENSITIVE!
BE CAREFUL!" warning attached to them) for ssl:connection_information/2.

However, what does it mean to start a connection in "debug mode"? The
string "debug" neither appears in the ssl module documentation, nor in
its source code (OTP 19.2). Isn't limiting access to those parameters to
an explicit request (via ssl:connection_information/2) a sufficiently
high barrier? Why require one to start a connection in a special mode in
addition to making the explicit request for the parameters?


"debug mode" would be a new option (maybe called something else) that
when set connection_information would be allowed to return  
master_secret, server_random, and client_random. This to ensure
that it is the intent of the connection starter that this behaviour should be allowed. 



> What if someone thinks its a good idea to decrypt the data
> outside the TLS connection in the server and send it to an
> external logging server in the clear!

The server already has the plaintext that was transferred through the
TLS tunnel. TLS doesn't protect you from your peer, it protects you from
someone in the middle. :)


Well yes the peer can choose to handle the plain-text uncarfully and TLS can do nothing about it.
I think there is  a reason for the joke (a)lawful interception ;)
The point here is that if it seems to standard (normal API) people might use it out of convinance for
testing/debuging or not understanding better and end up compromising security. 

 
> What if someone decides to transfer the logs in an insecure way from
> the server!

Sure, but "malicious or poorly-thought-out TLS peers (or system
operators)" are -AFAICT- outside the scope of the protection that TLS
provides. Given that both OpenSSL and BoringSSL provide functions to
extract client/server random and master secret, it seems that there is a
legitimate (if niche) reason for exposing this information to clients.

I mean, the Erlang ssl module allows you to turn off BEAST mitigation
and the block cypher padding check. These options are arguably more
dangerous than what's being discussed (as they weaken TLS's MITM
protections (leaving you open to POODLE and BEAST)) but they are _very_
useful in certain niche situations.


Yes interop vs security can be a tradeoff. All these needs the user to make an
active choise.

Regards Ingela Erlang/OTP team - Ericsson AB

 


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL: Getting master_secret and client_random (or premaster_secret)

Kenneth Lakin
On 01/13/2017 10:57 AM, Ingela Andin wrote:
> Yes interop vs security can be a tradeoff. All these needs the user to make
> an active choise.

Notably, that active choice _doesn't_ include forcing the programmer to
also start the connection in "interop mode". Marking those ssl_options
with Big Red Dire Warnings was (correctly) deemed quite enough notice. :)

Heck, verify_fun is documented as normal, non-hazardous (that is, it
lacks a Big Red Warning box) API, but can be misused to (accidentally)
seriously compromise one's connection security. verify_fun does _not_
depend on an "enable_hazardous_options" connection flag.

> This to ensure that it is the intent of the connection starter
> that this behaviour should be allowed.

Given that the caller can bypass this check by pulling the PID out of
the SSLSocket, calling sys:get_state/1 and extracting the
security_parameters, this check seems to be more of an annoyance than
anything else. For instance, how would the author of the (hypothetical)
TLS connection pool library I'm using know that I _never_ will have a
legitimate need to extract the client_random from a connection it
establishes for me?



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL: Getting master_secret and client_random (or premaster_secret)

Ingela Andin


2017-01-13 21:27 GMT+01:00 Kenneth Lakin <[hidden email]>:
On 01/13/2017 10:57 AM, Ingela Andin wrote:
> Yes interop vs security can be a tradeoff. All these needs the user to make
> an active choise.

Notably, that active choice _doesn't_ include forcing the programmer to
also start the connection in "interop mode". Marking those ssl_options
with Big Red Dire Warnings was (correctly) deemed quite enough notice. :)

Heck, verify_fun is documented as normal, non-hazardous (that is, it
lacks a Big Red Warning box) API, but can be misused to (accidentally)
seriously compromise one's connection security. verify_fun does _not_
depend on an "enable_hazardous_options" connection flag.


verify_fun can be abused (maybe we should add a warning)
but it still in a smaller context however .....


 
> This to ensure that it is the intent of the connection starter
> that this behaviour should be allowed.

Given that the caller can bypass this check by pulling the PID out of
the SSLSocket, calling sys:get_state/1 and extracting the
security_parameters, this check seems to be more of an annoyance than
anything else. For instance, how would the author of the (hypothetical)
TLS connection pool library I'm using know that I _never_ will have a
legitimate need to extract the client_random from a connection it
establishes for me?



... maybe I am being to paranoid ;) Well it seem like  a good compromise would
be that connection_information will only return these values when explicitly requested
along with a warning in the documentation, as we can not protect against a malicious
attacker that has access to the node anyway. 


Regards Ingela Erlang/OTP team  - Ericsson AB




_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL: Getting master_secret and client_random (or premaster_secret)

Ben Murphy-2
In reply to this post by Roger Lipscombe-2
We have a hacky way to do this on R19 (Probably only works for our
particular version because these internal records can change). We
hooked ssl:connect using the tracing facility because we couldn't
deploy a code change.

https://gist.github.com/benmmurphy/d2918d3aaea46372501b851814f4ce8a

DumpMS = fun() ->
     FindMs = fun(Socket) ->
          Pid = element(3, Socket),
          Connection = sys:get_state(Pid),
          State = element(2, Connection),
          Session = element(18, State),
          SessionId = element(2, Session),
          MasterSecret = element(7, Session),
          {SessionId, MasterSecret}
     end,

     Hex = fun(Id) -> << <<Y>> ||<<X:4>> <= Id, Y <-
integer_to_list(X,16)>> end,

     {ok, File} = file:open("/tmp/tls.log", [write, append]),

     DebugHandler = fun DebugHandler() ->

          receive
               {trace, _Pid, return_from, _MFA, {ok, Socket}} ->
                    try
                         {SessionId, MasterSecret} = FindMs(Socket),
                         Bytes =  io_lib:format("RSA Session-ID:~s
Master-Key:~s~n", [Hex(SessionId), Hex(MasterSecret)]),
                         file:write(File, Bytes),
                         ok
                    catch C:E ->
                         ok
                    end,
                    DebugHandler();
               quit ->
                    file:close(File),
                    ok;
               _ ->
                    DebugHandler()
          end,
          ok
     end,


     Pid = spawn(DebugHandler),

     register(ms_tracer, Pid),

     erlang:trace(processes, true, [{tracer, Pid}, call]),

     erlang:trace_pattern({ssl, connect, 2}, [{['_', '_'], [],
[{return_trace}]}]),
     erlang:trace_pattern({ssl, connect, 3}, [{['_', '_', '_'], [],
[{return_trace}]}]),
     erlang:trace_pattern({ssl, connect, 4}, [{['_', '_', '_', '_'],
[], [{return_trace}]}]),

     Pid

end.

QuitMS = fun() ->
     erlang:trace(all, false, [{tracer, whereis(ms_tracer)}, call]),
     ms_tracer ! quit
end.

On Thu, Jan 5, 2017 at 2:20 PM, Roger Lipscombe <[hidden email]> wrote:

> We're using ECDHE and DHE ciphers for our SSL connections. This
> provides perfect forward secrecy, which is good, but it makes it
> impossible to decipher packet captures in wireshark, which is
> expected, and also good, almost all of the time.
>
> Sometimes, however, we *do* need to decipher the traffic.
>
> Note that we own both the client (which is embedded) and the server
> (which uses Erlang -- otherwise I wouldn't be asking here -- and
> ranch). We *could* offer a different cipher suite on the server, which
> would disable PFS, but would do it for all connections. I'd prefer
> something a bit more fine-grained.
>
> You can feed a key log to Wireshark, as documented at
> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format,
> and it'll correctly decipher the traffic for that connection.
>
> I'd like to find a way to generate a key log file. This requires
> either (client_random, master_secret) or (encrypted_premaster_secret,
> premaster_secret).
>
> Note that I'm looking at the OTP 17.5 source, because that's what we're using.
>
> It would seem that premaster_secret is not stored past the initial
> negotiation, but the client_random and master_secret values are in the
> #security_parameters record in the #connection_state record in the
> #connection_states record, which is in the #state record of the SSL
> connection pid.
>
> But I can't see any (clean) way to retrieve these values, in order to
> generate a key log suitable for Wireshark.
>
> Is there any clean way to do this in OTP 17.5, or is there a supported
> way to do this in OTP 18.x or 19.x?
>
> Regards,
> Roger.
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Loading...