Neverbleed

Security and privacy

privilege separation for tls private keys

SHOW HN2015

Neverbleed

privilege separation engine for OpenSSL and LibreSSL

github.com

#openssl#privilege separation#rsa#libressl#tls

47points
12comments
#598of 2,565 in 2015
Top 24%of 2015 by points

How HN took it

DebatedReal support and real criticism

3 positive, 2 neutral or asking, 0 mixed, 2 critical, out of 7 comments about the project. Thread score +0.11.

Performance: 1 for, 2 againstDocs: 1 for, 0 againstIdea: 1 for, 0 against

The thread, comment by comment

Each row is a top-level comment and its replies, in HN's order. Select a cell to open that comment on HN.

positive neutral or mixed critical about another commenter or something else the maker

What HN said

What people liked

  • Simple, clearly documented API for OpenSSL users

    From 1 comment
    • As an implementor using OpenSSL, I like this. It has a simple API, and is clearly documented. I wish all security improvements were as simple and easy.
      adekok on HN
  • Low overhead expected

    From 2 comments
    • probably lower overhead. PKCS#11 is a lot bigger than this.
      acveilleux on HN
    • Why would it matter? He already has an uphill battle with virtualization and seems a minimal amount of overhead. I expect running this on big iron should show similar or less…
      feld on HN

Objections

  • RSA operations over IPC block the event loop in event-loop servers

    From 2 comments
    • I applaud the effort but it does not address the elephant in the room: openssl engines are synchronous. If you use openssl in an event-loop style server (coincidentally, OP's own…
      fefe23 on HN
    • Inter-process IPC is going to block the event loop for longer than a inline RSA operation.
      pquerna on HN
  • Overhead may be significant on high-end termination systems, untested there

    From 1 comment
    • Seems like a good idea, but it also seems like a lot of IPC. The author suggests that crypto costs more than IPC, so it doesn't matter much, which also seems reasonable, and I…
      ibejoeb on HN
  • Blocking IPC could limit new connections per second in single-threaded servers

    From 1 comment
    • The point is that it requires TLS handshakes to be done in a multi-threaded system for a server handling high concurrency. Many servers are multi-threaded, but many are not.…
      pquerna on HN

Requests

  • Benchmarks on high-end server hardware

    From 1 comment
    • Seems like a good idea, but it also seems like a lot of IPC. The author suggests that crypto costs more than IPC, so it doesn't matter much, which also seems reasonable, and I…
      ibejoeb on HN
  • An LD_PRELOAD version

    From 1 comment
    • Someone should make an LD_PRELOAD hack for this. I might try throwing one together this weekend if someone doesn't beat me to it.
      ryan-c on HN

Questions

  • How does it differ from SoftHSM?

    From 1 comment

Alternatives named

  • Keyless SSL (Cloudflare)

    From 2 comments
    • I applaud the effort but it does not address the elephant in the room: openssl engines are synchronous. If you use openssl in an event-loop style server (coincidentally, OP's own…
      fefe23 on HN
    • I assume you are referring to Keyless SSL. https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/ For Keyless SSL, it is necessary to make RSA operations…
      kazuho on HN
  • SoftHSM / PKCS#11

    From 2 comments

Category, keywords, summaries and labels on this page were made by AI (Thread Reader v2) and not checked by hand. Each point links to the comments it came from.

Add a badge to your READMEShown on HackerShow
[![Shown on HackerShow](https://hackershow.org/badge.svg)](https://hackershow.org/show/10263410)