Repository navigation
Add TLS Record Layer - #18
Conversation
FranzBusch
left a comment
FranzBusch
left a comment
There was a problem hiding this comment.
Excited to see this addition but I have a few questions regarding the details of it.
| } | ||
|
|
||
| public mutating func processNetworkData(networkDataIn: RawSpan) throws(SwiftTLSError) { | ||
| var buff = ByteBuffer(copying: networkDataIn) |
There was a problem hiding this comment.
There is a lot of copying going on the PR. Have we thought about doing as much of the processing without copying?
| var message = [UInt8](unsafeUninitializedCapacity: encryptedRecord.byteCount) { buffer, initializedCount in | ||
| encryptedRecord.withUnsafeBytes { encryptedBuffer in | ||
| UnsafeMutableRawBufferPointer(buffer).copyMemory(from: encryptedBuffer) | ||
| } | ||
| initializedCount = encryptedRecord.byteCount | ||
| } |
There was a problem hiding this comment.
We should be able to do this without unsafe code by using the OutputSpan based APIs instead.
| try message.withUnsafeMutableBytes { (messageBuffer) -> Result<(), CryptoKitMetaError> in | ||
| var ciphertextSpan = UnsafeMutableRawBufferPointer( | ||
| rebasing: messageBuffer[0..<ciphertextLength] | ||
| ).mutableBytes | ||
| let tagSpan = UnsafeMutableRawBufferPointer( | ||
| rebasing: messageBuffer[ciphertextLength..<encryptedRecord.byteCount] | ||
| ).mutableBytes |
There was a problem hiding this comment.
Why are we not using the extracting APIs on Span here to avoid the proliferation of unsafe code?
| try tagSpan.withUnsafeMutableBytes { tagBuffer throws(CryptoKitMetaError) in | ||
| var tagBytes = OutputRawSpan(buffer: tagBuffer, initializedCount: 0) |
There was a problem hiding this comment.
Why are we going from a span to an unsafe buffer to a span again? We should be able to go all the way using just safe Span APIs here unless I am missing something.
|
Tried to address some of the unsafe code with #19 |
This PR reduces and isolates the unsafe code introduced in apple#18 to a minimum. This helps with ensuring that the TLS record layer implementation is as safe as possible.
5 participants
This PR brings the TLS 1.3 record layer into the package, completing the path from raw network bytes to handshake messages and application data. TLSRecordParser incrementally reassembles records off the wire, TLSCiphertext/TLSInnerPlaintext handle AEAD protection and deprotection, TLSRecordProtector owns key and IV derivation along with per-record nonce construction, and TLSRecordHandler ties it together, driving the client and server handshake state machines, fragmenting outgoing messages across records, and rotating keys as encryption levels advance.
Added SwiftTLSHandshakeAndRecordManager to SwiftTLSProtocol.swift, the public entry point that wraps a record handler and exposes handshake progress, application data, and outgoing bytes to callers. CryptoWrappers.swift provides span-free fallbacks so the layer builds against Crypto releases without the newer span-based APIs. Added tests as well to cover record layer operations.