4 ms·

Totally Isolated TLS Unwrapping Server

45 points by reader_1000 11y ago

ch 11y ago
Storing the private key material in a separate process is a nice touch.
yxhuvud 11y ago
Isn't the normal term for this to terminate TLS, not unwrap it?
- sigio 11y ago
  That wouldn't fit in a nice acronym
  - nly 11y ago
    I dunno. TITTS seems pretty memorable to me
    - yxhuvud 11y ago
      A bit too memorable perhaps.
- agwa 11y ago
  The name is inspired by stud (Scalable TLS Unwrapping Daemon), another TLS termination server with a cool acronym.
- cperciva 11y ago
  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.
gima 11y ago
"Uses a separate process for every TLS connection" sounds scalable.
- lmm 11y ago
  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?
  - ryanpetrich 11y ago
    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.
- agwa 11y ago
  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.
ericlathrop 11y ago
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.
- agwa 11y ago
  (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.
  - aristus 11y ago
    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.
    - agwa 11y ago
      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.
  - reader_1000 11y ago
    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"
- loginusername 11y ago
  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.
lemonade 11y ago
You might want to look at: https://tlspool.arpa2.net/ https://tlspool.arpa2.net/
nulltype 11y ago
Is there any info about the per connection memory usage?

45 points by reader_1000 11y ago

ch 11y ago

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

yxhuvud 11y ago

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

sigio 11y ago
That wouldn't fit in a nice acronym
- nly 11y ago
  I dunno. TITTS seems pretty memorable to me
  - yxhuvud 11y ago
    A bit too memorable perhaps.
agwa 11y ago
The name is inspired by stud (Scalable TLS Unwrapping Daemon), another TLS termination server with a cool acronym.
cperciva 11y ago
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.

gima 11y ago

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

lmm 11y ago
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?
- ryanpetrich 11y ago
  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.
agwa 11y ago
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.

ericlathrop 11y ago

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.

agwa 11y ago
(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.
- aristus 11y ago
  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.
  - agwa 11y ago
    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.
- reader_1000 11y ago
  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"
loginusername 11y ago
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.

lemonade 11y ago

You might want to look at: https://tlspool.arpa2.net/ https://tlspool.arpa2.net/

nulltype 11y ago

Is there any info about the per connection memory usage?