<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    We already have the file based ticket keys. They require an external
    rotation, but I think that this requirement is okay for admins that
    already have to think of an exchange between several instances.<br>
    <br>
    Richard<br>
    <br>
    <div class="moz-cite-prefix">On 9/22/2014 2:23 PM, kyprizel wrote:<br>
    </div>
    <blockquote
cite="mid:CAAk1GzKiB6usNVGU0_QXiEONLU9gYm_rLU6tMZT9kHoTbZmgnw@mail.gmail.com"
      type="cite">
      <div dir="ltr">What about sharing keys b/w the physical instances?<br>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Mon, Sep 22, 2014 at 3:39 PM,
          Richard Fussenegger, BSc <span dir="ltr"><<a
              moz-do-not-send="true"
              href="mailto:richard@fussenegger.info" target="_blank">richard@fussenegger.info</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">I'd like
            to implement built-in session ticket rotation. I know that
            it this was discussed before but it was never implemented.
            Right now a custom external ticket key system is supported.
            Admins with single installations and not enough knowledge
            about the topic are left with keys that are valid for the
            complete lifetime nginx is running.<br>
            <br>
            I thought about a rotation scheme that introduces a single
            new configuration variable (e.g. ssl_session_ticket_key_rotation
            or ssl_session_ticket_key_interval) that defines the
            interval in which the ticket key should be rotated. I think
            a default setting of 24 hours would be enough for most
            installations. One key is always used for decryption and
            encryption and the most recently expired key is only used
            for decryption. This means that we have a de- and encrypt
            key for 24 hours and a decrypt key for 48 hours with the
            default setting. The best place for this would be in
            ngx_event_openssl.c#2640 after the if (paths == NULL) by
            checking if the aforementioned variable is set (default) and
            if the currently used key has expired. If it hasn't return
            NGX_OK (as it is now) otherwise copy current key to old key
            and generate new key.<br>
            <br>
            Unsolved questions:<br>
            <br>
            Implementation: Currently OpenSSL is generating and keeping
            track of the key (this would still be the case if the newly
            introduced setting is set to "0"). We'd have to introduce
            two variables - one for the current and one for the old key
            plus timestamps - and let OpenSSL know about the key before
            attempting to decrypt sent session data.<br>
            <br>
            Per server keys: CVE-2014-3616 from Antoine Delignat-Lavaud
            was dealing with this. I have to review his patches but I
            guess that the variables have to be arrays and we'd have to
            keep different current and old keys per server. But what if
            one wants to share the sessions among servers? I guess this
            has to depend on the location the configuration was set. As
            I said, I have to review his patches to gather more
            knowledge for this problem.<br>
            <br>
            Restarts: Apache is storing the key to file, that would
            allow the process to read the last used keys. But of course
            this isn't very secure and we may need an additional setting
            to define the path where these intermediate keys should be
            stored. Of course we could also simply ignore restarts, as
            it is now. But we'd loose the ability to decrypt old
            sessions tickets.<br>
            <br>
            Any thoughts from your side are highly appreciated.<br>
            <br>
            Richard<br>
            <br>
            _______________________________________________<br>
            nginx-devel mailing list<br>
            <a moz-do-not-send="true"
              href="mailto:nginx-devel@nginx.org" target="_blank">nginx-devel@nginx.org</a><br>
            <a moz-do-not-send="true"
              href="http://mailman.nginx.org/mailman/listinfo/nginx-devel"
              target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-devel</a><br>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
nginx-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a>
<a class="moz-txt-link-freetext" href="http://mailman.nginx.org/mailman/listinfo/nginx-devel">http://mailman.nginx.org/mailman/listinfo/nginx-devel</a></pre>
    </blockquote>
    <br>
  </body>
</html>