SwiftTLS – A TLS implementation in Swift

by andreasley • 8 years ago

68 18 8 years ago

wahern3• 8 years ago

Now refactor everything to support async/await to support asynchronous use in addition to synchronous use. And then you'll have the answer as to why async/await and stackless coroutines are a dead-end.

eridius• 8 years ago

Did you comment on the right story?

wahern3• 8 years ago

TLS stacks are dead out of the water if they don't support non-blocking I/O.

The point of my post wasn't to criticize SwiftTLS, per se, but rather to make a larger point that supporting asynchronous I/O will never become substantially easier unless and until languages provide the correct primitives. Case in point: try to refactor SwiftTLS (which otherwise may be a laudable TLS implementation) to support Swift's async/await proposal. All the headaches and compromises will say much more about the viability of async/await than about the implementation quality of SwiftTLS. Nonetheless, it's the end product (SwiftTLS, etc) that will be bear the blame for the added complexity (or lack thereof if they abstain from supporting the model).

andreasley• 8 years ago

SwiftTLS is non-blocking (using Dispatch). Yes, many libraries will have to be updated when async/await arrives, but I'd say that's business as usual for Swift developers (who have to do some refactoring every year anyway).

Also, SwiftTLS is not meant to be used in a production environment at this point. The disclaimer states: "It is not ready, has certainly a lot of bugs and received virtually no real world testing yet."

kodablah2• 8 years ago

I wonder how many times we'll impl tls, http 2, aes, etc or how many times we'll leverage libs with C ffi. I'm not sure about Swift's CSP support, but I'm beginning to think translating Go everywhere, except for some of the core (or other asm-level pieces like constant time byte array actions) that may be language specific, may be a better way to open up tons of libs for use. It's a fairly simple and unchanging source language. I know Haxe has these kinds of goals, but I figure the ecosystem is weaker.

Spartan-S632• 8 years ago

I don't see Go as a panacea for opening up libraries for use. You're still going to see languages that can export C interfaces for that. It's going to be C, C++, and Rust that are likely to persist as the languages of choice for massively consumable libraries. As long as they can export a C interface, you can get low (or no) overhead interop. Go's biggest disadvantage is that it ships by default with a runtime.

I hope I'm understanding your comment correctly.

bigdubs• 8 years ago

C interop can introduce a lot of complexity in the build toolchain. It's nice to have native versions of libraries like this, vs. relying on compiling c/c++/rust versions.

kodablah2• 8 years ago

I meant translate the actual Go code to Swift code so it's pure Swift, but the effort to implement the algorithm right is removed. But yes, to support Go's features you will need at least a GC. Once Rust gets async/await down and people run with it, a static lib in Rust w/ an exported C interface might instead be the norm. But in the meantime, it's annoying that the options are to either reuse a complicated/unsafe C/C++ impl or re-impl in each language individually. Go has a terrible C export story with lots of limitations and impedance mismatches so that's not a great approach imo (granted it's what gomobile does iirc).

pjmlp• 8 years ago

On Windows we have better interop story via COM/UWP or .NET.

On Android the interop story is Java and on the Web it is going to be either JavaScript or WebAssembly.

brainzap• 8 years ago

I started using the Go source code to look up how to implement X.

MaxBarraclough• 8 years ago

I wonder how many times we'll impl tls, http 2, aes, etc

Well, they're not really for production, are they?

For production, shouldn't we all be using the fastest, best-tested implementation, presumably in either C or assembly?

moderation• 8 years ago

All of the TLS 1.3 implementations and test servers (including SwiftTLS) are listed at https://github.com/tlswg/tls13-spec/wiki/Implementations#imp...

pharaohgeek• 8 years ago

Better crypto support in platform-agnostic Swift is definitely #1 on my wishlist. On macOS/iOS you have Apple's libraries to provide cryptographic support. However, for server-side Swift running on Linux, your options are pretty much reduced to wrappers around OpenSSL. I'd love to see more formal cryptographic and security libraries for Swift. While Java's JCE definitely has its flaws from a design perspective, something along those lines for Swift would greatly enhance its viability for enterprise software, or other applications where security is of paramount concern.

SwiftTLS – A TLS implementation in Swift

Related Stories