News for hackers. Stuff that matters.
Re:The spiped secure pipe daemon by tptacek on Monday July 04, 2011 @01:35PM (#2727180)
There's a lot of code in stunnel, but much of it isn't in security-critical code paths. I'm not sure stunnel <-> stud is an apples-apples comparison.
Re:The spiped secure pipe daemon by cperciva on Monday July 04, 2011 @01:39PM (#2727195)
Unless 95% of stunnel's code is in non-security-critical code paths, it still has considerably more security-critical code than stud.
Re:The spiped secure pipe daemon by tptacek on Monday July 04, 2011 @01:42PM (#2727202)
I've read both stunnel and stud and 95% might ... just ... be on the high side of a reasonable estimate there. Again, I'm saying: stud <-> stunnel is not an apples-apples comparison.

The reality here, and I think you should just come out and say it, is that the rationale behind spiped is that you don't trust SSL/TLS period.

What's the deal with the per-message padding scheme here? Is this a tradeoff against rekeying?

Re:The spiped secure pipe daemon by cperciva on Monday July 04, 2011 @01:55PM (#2727247)
The reality here, and I think you should just come out and say it, is that the rationale behind spiped is that you don't trust SSL/TLS period.

That's part of it, sure. But SSL/TLS also doesn't provide client authentication (unless you use client SSL keys, which is absolutely guaranteed to have security holes given that nobody ever uses them).

What's the deal with the per-message padding scheme here?

1. Makes the code much simpler and less error-prone (no need to read variable-length records from the network).

2. Cuts down on information leakage. I'm planning on using this for kivaloo, which uses variable-length records -- I don't want to expose the lengths of account names or suchlike.

Re:The spiped secure pipe daemon by tptacek on Monday July 04, 2011 @02:28PM (#2727342)
Client SSL certificates are very common in non-web TLS settings.
Re:The spiped secure pipe daemon by btilly on Tuesday July 05, 2011 @04:00AM (#2729036)
What exactly is a "security-critical code path"?

Considering that a pointer mistake in code that you didn't think was security critical might allow execution of arbitrary code, aren't all code paths that might execute, security critical?