Hi Jesus Albertot,

You are more than welcome to intergate LURK with OpenSSL and NGINX. We
discussed this during the hachathon in London, so feel free to share your
thoughts or questions on the mailing list. I am sure you will get some
interesting feed backs.

If I understand correctly your question is whether the Key Server should
only "decrypt" the premaster versus computing the master secret.

One reason is to limit the scope of usage of the private key. Returning the
premaster can be used by any attacker to decrypt any random bytes ( of the
size of the premaster ) which could be used outside the scope of a TLS
session. Returning the master, instead limits the usage outside the scope
of TLS. A typical attack could consist in asserting you are the company "
www.example.com" and ask users to rely on the RSA public key to encrypt
some data. An attacker corrupting a edge server to gain access to the key
server could decrypt this data and as such impersonate "www.example.com".
In this example data is outside the scope of a TLS session. Returning the
master requires the attacker to reverse the master to the premaster to
access data which is harder to do.

Another reason is that within the scope of TLS providing the master enables
to provide perfect forward secrecy, and in our case the inability to
regenerate a master secret from an observed TLS key exchange. If the key
server returns the premaster, an attacker corrupting a edge server to gain
access to the key server and observing a TLS key exchange is able to access
the master and decrypt the TLS session. If the attacker does not have
physically access to the private key, he will have the opportunity to
perform the operation it needs. The purpose of PFS is to prevent that a TLS
key exchange can be replayed even if you have access to the Key Server. The
mechanism currently described is the one from [1] which uses a one one-way
function. The key server and the edge server uses hash( R ) for the server
random. A passive observer will see H( R ) on the wire, and needs to send R
to the Key Server for the generation of the master. This is assumed to be a
difficult operation.

This mechanism prevents requesting the Key Server from an observed TLS key
exchange. However,  we do not prevent "illegitimate" exchange to happen,
that is request outside a TLS exchange. Note also that by providing the
master, the edge server is able to do session resumption.... The following
document provides a security analysis of KeylessSSL [2].

Thank you for raising this question and please feel free to raise your
concern.

Yours,
Daniel


[1] https://tools.ietf.org/html/draft-erb-lurk-rsalg-01
[2] https://epubs.surrey.ac.uk/813643/1/mainKeyless.pdf




On Mon, Apr 9, 2018 at 4:32 AM, Jesús Alberto Polo <i...@jesusalberto.me>
wrote:

> Hi,
>
>
> I’m currently working on an implementation of LURK to be integrated with
> OpenSSL and NGINX. After having identified all main parts and started the
> development, I have some questions regarding the LURK extension for (D)TLS
> 1.1 and 1.2 draft, more specifically for RSA as key exchange method
> (rsa_master, section 5).
>
>
> As I understand, the Edge Server (LURK client) only needs the Private Key
> to decrypt the premaster secret sent by the TLS client. I would like to
> understand why LURK server computes the master secret instead of only
> decrypting the premaster secret and letting the Edge Server compute the
> master secret (since it is terminating the TLS connection). In this way:
>
>
>    1. the LURK server would still protect the private key.
>    2. it’d be less intrusive for the TLS protocol (the only change is the
>    remote decryption instead of local decryption), it’d have less impact on
>    the OpenSSL code as well.
>    3. less error handling (however, LURK server would have less control
>    over the cyphers, TLS versions, PRF functions…).
>    4. the master secret would be locally computed by the TLS server and
>    never sent through the network (that is, even if an attacker compromises
>    the secure connection between LURK client and server and steals the
>    decrypted premaster key, they still need for other values of the TLS
>    connection in the LURK client).
>
> Thank you in advance.
>
>
> Best regards,
>
> Jesús Alberto
>
> _______________________________________________
> Lurk mailing list
> Lurk@ietf.org
> https://www.ietf.org/mailman/listinfo/lurk
>
>
_______________________________________________
Lurk mailing list
Lurk@ietf.org
https://www.ietf.org/mailman/listinfo/lurk

Reply via email to