Totally Isolated TLS Unwrapping Server | Hacker News Reader

Totally Isolated TLS Unwrapping Server

opsmate.com

45 pointsreader_100019 comments

Open articleView on HN

You might want to look at:

https://tlspool.arpa2.net/

Storing the private key material in a separate process is a nice touch.

Isn't the normal term for this to terminate TLS, not unwrap it?

That wouldn't fit in a nice acronym

I dunno. TITTS seems pretty memorable to me

A bit too memorable perhaps.

The name is inspired by stud (Scalable TLS Unwrapping Daemon), another TLS termination server with a cool acronym.

I believe that I'm responsible for that. Jamie Turner asked me to review bump's STUD, which was at that point the "Scalable TLS something daemon"; I suggested to him that the "something" could be "unwrapping" and would both make sense and make the acronym work.

You'd have to ask Jamie to be sure, though. It's entirely possible that someone else suggested this too.

"Uses a separate process for every TLS connection" sounds scalable.

It should be - the OS's whole job is to manage processes. I mean if it's allocating 4kb of physical memory to each then that would scale poorly, but who does that?

4KB is the size of a page on x86 and most architectures, the smallest unit of memory the OS can dispense. SSL termination is definitely a function you don't want the kernel to swap to disk, therefore each connection would get at least 4KB of physical memory under a process-per-connection model.

There's a cost to the isolation. It's not for everyone.

Ultimately, I'd like to provide a knob to the administrator to control how much isolation they'd like. If you can't afford full isolation, you could tell titus to service multiple connections per process. titus would only do so if the server was under load, and would recycle processes frequently so memory wouldn't stick around for too long. But this would require complicated changes which I haven't had time for yet.

Is there any info about the per connection memory usage?

  The current version of titus is 0.2, released on 2014-08-17.

I'd be wary of using any piece of security software that hasn't had a release in over a year.

(Author here.) I'd be more wary of using security software that changes frequently, since every code change is an opportunity for a new security vulnerability to be introduced. I'm very cautious with changes to titus.

That said, 0.3 will be released any day now. It's pending testing of the new FreeBSD support.

This looks great. Any tips on how to terminate mixed-mode protocols like MySQL's SSL mode and IMAP's STARTTLS? Vanilla unwrapper daemons generally don't handle the case of initial unencrypted bit twiddling, and then SSL negotiation.

Unfortunately not. STARTTLS is the bane of standalone TLS terminators like titus, which is one of the reasons I really dislike STARTTLS. I won't rule out titus supporting STARTTLS some day, but the idea of integrating parsers for a bunch of different protocols into titus is really unappealing.

Is there a roadmap to reach 1.0 release? I wondered because of this statement in your web site: "it has not yet undergone serious testing or performance optimization. Additionally, we may make backwards-incompatible changes to the behavior before titus reaches version 1.0"

Any program that is constantly being updated and/or re-released is, for me, the one I'm more wary about trusting. As an example, look at djb's software. After a period in the beginning, you do not see the constant releases and updates.

To me, trustworthy software is software that is "correct", if that is even attainable.

Ideally, if the author is truly careful, it should be close to "correct" when it initially released.

Numerous releases and updates year after year to me suggests the software was not very close to correct when the author decided it was time to release. Or that the author is pandering to feature requests.

As with the parent comment, this is only an opinion.

NaCl and CurveCP have not been updated in years. But I feel it's more trustworthy than TLS.

I'm just a fool I guess.

Reply on news.ycombinator.com