Introducing s2n, a New Open-Source TLS Implementation • Hacker News Board

Re: Introducing s2n, a New Open-Source TLS Implementation

#101

Post by halayli » Wed, Jul 01, 2015, 7:27 PM UTC

cperciva wrote: post #81

halayli wrote: post #76

Earlier quoted context omitted.

Just because you haven't come across client cert validation requirement, it doesn't mean it's wrong. If you have a bunch of micro services that need to communicate with each other securely, client cert validation solves a big problem.

If you have a bunch of small services which need to communicate securely, you should be using something like spiped, not TLS. TLS is the right solution iff you need to communicate with third parties whom you can't securely share code or keys with in advance.

don't throw solutions with confidence like they are silver bullets. spiped is unmaintained, doesn't support revocation, not easy to debug in a big infrastructure, and will require a lot more work compared to https + client cert authentication, and doesn't provide multi platform support.

PKI is used to build a chain of trust. Whether it involves third parties or not is not the point.

Re: Introducing s2n, a New Open-Source TLS Implementation

#102

Post by amirmc » Wed, Jul 01, 2015, 10:14 PM UTC

minthd wrote: post #98

amirmc wrote: post #97

Earlier quoted context omitted.

Isn't that pretty much what we have already with things like openSSL? Find an exploit and suddenly you've exposed everyone. I don't think public bounties would change any of the dynamics around this situation.

With the current system, if you're using an exploit(especially for gain), you're a criminal.Not so when using pinata. Also , pinata exposes all hacks in public, unlike today.

My point is that I don't believe any of the dynamics would actually change. White hats would still report issues (they're not necessarily doing it for the money) and nefarious types will still trade/sell exploits.

Re: Introducing s2n, a New Open-Source TLS Implementation

#103

Post by lmm » Thu, Jul 02, 2015, 8:50 AM UTC

cperciva wrote: post #100

mzs wrote: post #99

Earlier quoted context omitted.

Autotools for these pretty simple things is an okay approach, but then people tend to go overboard, and that's when it gets horrible (or autoconf itself breaks libxnet detection cause it gets some quoting or who knows what wrong in some release). My personal pet peeve is people detecting endian in obtuse ways that totally fails during cross-compiling when there's the perfectly fine ntoh family.

You don't even need autotools for those simple things though.

You don't need autotools, but autotools is the consistent way to do it; the "installed base" is large enough that any sysadmin knows how to deal with autotools (and will have to for many years). Writing your own custom check, even if that check is much more concise in and of itself, makes it harder for a sysadmin to understand your project build than just doing the same thing as every other project.

Re: Introducing s2n, a New Open-Source TLS Implementation

#104

Post by irv » Tue, Jul 07, 2015, 2:27 PM UTC

halayli wrote: post #101

cperciva wrote: post #81

Earlier quoted context omitted.

If you have a bunch of small services which need to communicate securely, you should be using something like spiped, not TLS. TLS is the right solution iff you need to communicate with third parties whom you can't securely share code or keys with in advance.

don't throw solutions with confidence like they are silver bullets. spiped is unmaintained, doesn't support revocation, not easy to debug in a big infrastructure, and will require a lot more work compared to https + client cert authentication, and doesn't provide multi platform support. PKI is used to build a chain of trust. Whether it involves third parties or not is not the point.

you're replying to the author, and maintainer, of spiped.