Uploaded image for project: 'Erlang/OTP'
  1. Erlang/OTP
  2. ERL-828

Consider accepting a fun returning the key or other sensitive options

    Details

    • Type: New Feature
    • Status: In Progress
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: kernel, sasl, stdlib
    • Labels:
      None

      Description

      An interesting discussion came up on IRC so I figured I'd echo it here.

      A solution less draconian to passing around sensitive data is to wrap it in a fun, this way logs and traces only see the fun, not the actual sensitive data. Therefore if we could wrap the key value in a fun immediately upon retrieval and pass it as a fun to ssl, which would only call the fun when necessary, we could hide the sensitive information entirely where it is only passed around or stored (not used). The fun could also just wrap location info and retrieve the key only when it's getting used, reducing the span where the actual value exists in the system.

      What do you think, should ssl accept a fun for the key? Is there other sensitive options this might be useful for?

      Idea originally from Dave Cottlehuber.

        Activity

        Hide
        i.khaprov@gmail.com Ilya Khaprov added a comment -

        in my case it's not tls connections I'm talking about, just poolboy and other regular stuff.

        Show
        i.khaprov@gmail.com Ilya Khaprov added a comment - in my case it's not tls connections I'm talking about, just poolboy and other regular stuff.
        Hide
        ingela Ingela Anderton Andin added a comment -

        Hum... what logger functionality are you using. Progress reports are not printed by default.
        Maybe you should not enable them in a production environment. It should also be possible
        to write filters to not allow the arguments to be logged.

        Show
        ingela Ingela Anderton Andin added a comment - Hum... what logger functionality are you using. Progress reports are not printed by default. Maybe you should not enable them in a production environment. It should also be possible to write filters to not allow the arguments to be logged.
        Hide
        michaelklishin2 Michael Klishin added a comment -

        I think I have a guess about the background here.

        It's a recurring theme for RabbitMQ to have a user run a security scan that feeds various ports garbage and then tries to sniff if any credentials included into those requests in the logs (typically this is done to HTTP listeners).

        RabbitMQ/Cowboy/etc simply run into an exception and log all request context/state, which includes those passed in credentials. Is that a real security issue? Of course not, even if the attacker would have access to the logs they would find the very same credentials they sent.
        Yet no one seems to care about the specifics at large corporations. A security tool they bought for a few bajillion $$$ says there is a problem, so RabbitMQ/Cowboy/etc get the reputation of tools that log passwords even though they obviously never do so intentionally.

        This goes well beyond the ssl app, of course. Erlang's "dump full process state by default" is helpful in root cause analysis but also a major liability in cases such as above.

        Not all users can or willing to write filters. State data structures also can be large, nested and change over time, so writing filters can be very error prone.

        Show
        michaelklishin2 Michael Klishin added a comment - I think I have a guess about the background here. It's a recurring theme for RabbitMQ to have a user run a security scan that feeds various ports garbage and then tries to sniff if any credentials included into those requests in the logs (typically this is done to HTTP listeners). RabbitMQ/Cowboy/etc simply run into an exception and log all request context/state, which includes those passed in credentials. Is that a real security issue? Of course not, even if the attacker would have access to the logs they would find the very same credentials they sent. Yet no one seems to care about the specifics at large corporations. A security tool they bought for a few bajillion $$$ says there is a problem, so RabbitMQ/Cowboy/etc get the reputation of tools that log passwords even though they obviously never do so intentionally. This goes well beyond the ssl app, of course. Erlang's "dump full process state by default" is helpful in root cause analysis but also a major liability in cases such as above. Not all users can or willing to write filters. State data structures also can be large, nested and change over time, so writing filters can be very error prone.
        Hide
        i.khaprov@gmail.com Ilya Khaprov added a comment -

        Well said Michael, Thanks!

        Show
        i.khaprov@gmail.com Ilya Khaprov added a comment - Well said Michael, Thanks!
        Hide
        ingela Ingela Anderton Andin added a comment -

        As I said we are not against allowing also funs to retrieve keys in the ssl applications even if obscuring logs would not be the main reason. I do understand the political argument. But I the workaround with funs as key retrievers in the ssl application could be seen as a workaround that may not solve the whole problem. I will assign this to our Product Owner.

        Show
        ingela Ingela Anderton Andin added a comment - As I said we are not against allowing also funs to retrieve keys in the ssl applications even if obscuring logs would not be the main reason. I do understand the political argument. But I the workaround with funs as key retrievers in the ssl application could be seen as a workaround that may not solve the whole problem. I will assign this to our Product Owner.

          People

          • Assignee:
            kenneth Kenneth Lundin
            Reporter:
            essen essen
          • Votes:
            2 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:

              Development