Apple's CoreTLS framework
Go to file
2023-05-01 11:31:03 -04:00
config coreTLS-167 2020-06-16 16:10:05 -04:00
coretls_cfhelpers coreTLS-167 2020-06-16 16:10:05 -04:00
coretls_performance coreTLS-83.20.8 2016-02-23 16:40:36 +01:00
coretls.xcodeproj coreTLS-167 2020-06-16 16:10:05 -04:00
kext coreTLS-167 2020-06-16 16:10:05 -04:00
lib Darling build of coreTLS-167 2020-06-18 14:10:01 -04:00
tls_client coreTLS-167 2020-06-16 16:10:05 -04:00
tls_test coreTLS-167 2020-06-16 16:10:05 -04:00
CMakeLists.txt Add install component declaration for cfhelpers 2023-05-01 11:31:03 -04:00
coretls.exp coreTLS-167 2020-06-16 16:10:05 -04:00
coverage.sh coreTLS-167 2020-06-16 16:10:05 -04:00
dummy.c coreTLS-83.20.8 2016-02-23 16:40:36 +01:00
Info-security_ssl.plist coreTLS-83.20.8 2016-02-23 16:40:36 +01:00
README coreTLS-83.20.8 2016-02-23 16:40:36 +01:00

===========
= coreTLS =
===========

*** Debugging ***

To enabled logging to syslog

    sudo defaults write /Library/Preferences/com.apple.security SSLDebugScope -bool true

On Release builds, only errors are logged (no warning or debug)

*** Test coverage analysis ****

There is a _coverage build variant of the libraries and tls_test app that can be used for code coverage analysis.
gcov does not work for libsystem components, so tls_test_coverage is statically linked to the coretls libraries.
As such you can only see test coverage data for tls_test.
(See: <rdar://problem/18126876> Test program crash after enabling gcov for libsystem component.)

To get coverage data, build tls_test in xocde, then run ./tls_test_coverage. The coverage data is stored alongside the .o files.
You can use CoverStory to visualize the data, by pointing it at the build folder.

The _coverage variant is only built for Debug.

*** SSL2 ***

Some client still send a SSL2 compatible Client Hello, even if they are trying to negotiate TLS 1.x,
In particular OpenSSL s_client. The record layer only support SSL3/TLS1.x decryption, but there is some
support to process SSL2 compatible Client Hello:


int
tls_stream_parser_parse(tls_stream_parser_t parser, tls_buffer data);

 This function will parse SSL2 records properly. But the callback does not include the record type as argument,
 so it will be necessary to verify again in the process callback.
 An SSL2 record should be passed directly to the tls_handshake_process() function, without attempting to decrypt.

int
tls_record_parse_ssl2_header(tls_record_t filter, tls_buffer input, size_t *len, uint8_t *content_type);

 Parse an SSL2 record header. Will return 0 if this is really a SSL2 record. The toral lenght of the record is 2+len.
 content_type will be set to tls_record_type_SSL2 (0x80).

int
tls_record_parse_header(tls_record_t filter, tls_buffer input, size_t *len, uint8_t *content_type);

 This will parse SSL2 record without errors, but the returned length will be bogus.
 The returned content type can be used to determine if this was an SSL2 record.
 content_type will be in the range 0x80-0xFF for SSL2 record.

Applications can directly check if a record is SSL2 or TLS by checking the first byte of the record,
which will be in the 0x80-0xFF range for SSL2