LINUX.ORG.RU

Linux kernel TLS

 ,


0

2

Привет всем есть кто-нибудь кто в ядре разбирается ? Подскажите как установить сокет клиент соединение к https серверу используя только linux kernel api без openssl/gnussl и тд. Поиском нашел только:

setsockopt(m_socket, SOL_TCP, TCP_ULP, "tls", sizeof("tls"));

struct tls12_crypto_info_aes_gcm_128 crypto_info;
crypto_info.info.version        = TLS_1_2_VERSION;
crypto_info.info.cipher_type    = TLS_CIPHER_AES_GCM_128;

vector<unsigned char> iv_write          (TLS_CIPHER_AES_GCM_128_IV_SIZE     , 0);
vector<unsigned char> seq_number_write  (TLS_CIPHER_AES_GCM_128_REC_SEQ_SIZE, 0);
vector<unsigned char> cipher_key_write  (TLS_CIPHER_AES_GCM_128_KEY_SIZE    , 0);
vector<unsigned char> implicit_iv_write (TLS_CIPHER_AES_GCM_128_SALT_SIZE   , 0);

memcpy(crypto_info.iv, iv_write.data()              , TLS_CIPHER_AES_GCM_128_IV_SIZE);
memcpy(crypto_info.rec_seq, seq_number_write.data() , TLS_CIPHER_AES_GCM_128_REC_SEQ_SIZE);
memcpy(crypto_info.key, cipher_key_write.data()     , TLS_CIPHER_AES_GCM_128_KEY_SIZE);
memcpy(crypto_info.salt, implicit_iv_write.data()   , TLS_CIPHER_AES_GCM_128_SALT_SIZE);

setsockopt(m_socket, SOL_TLS, TLS_TX, &crypto_info, sizeof(crypto_info))

но чем заполнить поля iv_write, seq_number_write, cipher_key_write, implicit_iv_write не нашел. Исходники openssl пока что не осилил. Результат выложу в открытый доступ.



Последнее исправление: volodja- (всего исправлений: 3)

Kernel TLS осуществляет формирование-парсинг записей и симметричное шифрование. Рукопожатие тебе нужно реализовывать самому, ещё до того как включишь SOL_TLS. Ну или взять готовую TLS реализацию.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

а много кода занимает реализация рукопожатия, если это не много кода может скопировать откуда-нибудь ?

volodja-
() автор топика
Ответ на: комментарий от volodja-

если это не много кода может скопировать откуда-нибудь ?

внезапно! http://web.mit.edu/KERBEROS/

только куда ты денешься от ssl, нужное для самого ядра ?

Gramozeka ★★
()
Ответ на: комментарий от volodja-

Реализация есть во всех библиотеках TLS. В зависимости от того, какую часть собираешься брать готовую, кода может быть и много, и мало. И ещё зависит от ожиданий.

Если твои ожидания объёма состоят в записи нескольких байт в сокет, то по сравнению с этим будет много. Вкратце: соединяешься с сервером, шлёшь информацию о себе, что умеешь, что поддерживаешь. Сервер шлёт информацию о том, что поддерживает он, сертификат и начинает согласование ключа. Ты отсылаешь свою часть согласования ключа. Проверяешь сертификат, вычисляешь ключ. Шлёшь серверу сигнал о том, что теперь от тебя всё будет шифрованное. Сервер шлёт тебе сигнал о том, что от него теперь будет всё шифрованное. Всё, рукопожатие закончено, дальше идёт обмен данными.

i-rinat ★★★★★
()
Ответ на: комментарий от volodja-

я бы взял OpenSSL, как мейнстрим

там всё просто, инициализируешь контекст сертификатом и приватным ключом, инициализируешь экземпляр структуры SSL, дёргаешь SSL_accept() если у тебя сервер, или SSL_connect(), если клиент, дальше при удачном хэндшейке как-то перенаправляешь дальнейшее взаимодействие на ядро

Harald ★★★★★
()
Ответ на: комментарий от volodja-

mbedTLS для некомерческого опенсорца.

anonymous
()

Хотя у mbedTLS апач2.0 лицензия, так что вообще пофиг где использовать.

anonymous
()
Ответ на: комментарий от Harald

Да, я начал с openssl, но когда прочитал новость, что в ядре 4.13 появилась поддержка tls, подумал что можно будет обойтись без лишней зависимости. Вот еще попалось сравнение производительности openssl, rustls и wolfSSL

https://jbp.io/2019/07/02/rustls-vs-openssl-bulk-performance.html

https://www.wolfssl.com/docs/benchmarks/

volodja-
() автор топика
Последнее исправление: volodja- (всего исправлений: 4)
Ответ на: комментарий от volodja-

А если твоя программа будет запускаться на дистре с ядром раньше 4.13? А если эту фичу не включат при компиляции ядра? А если тебе понадобится запускать эту программу не на ядре линукса? Проще взять OpenSSL и не пердолиться

Harald ★★★★★
()
Ответ на: комментарий от Harald

так сразу и надо было это предлагать. Разве что если лекция есть, да на русском.

Vault_Boy
()
Ответ на: комментарий от Harald

Я предпочел бы компактный код без зависимостей с поддержкой только последней версии tls(с возможностью потом дописать). На windows и macos можно использовать api ОС.

volodja-
() автор топика
Последнее исправление: volodja- (всего исправлений: 2)
Ответ на: комментарий от volodja-

ну да, поддержка 3 разных API делает код конечно же компактнее, с ifdef-ами и прочим

кстати, откуда на macos отдельный TLS API, там OpenSSL из коробки поставляется

Harald ★★★★★
()
Ответ на: комментарий от volodja-

Я предпочел бы компактный код без зависимостей с поддержкой только последней версии tls(с возможностью потом дописать). На windows и macos можно использовать api ОС.

Ну и чем тебя mbed TLS не устраивает? TLS1.3 там есть уже довольно давно.

kostyarin_ ★★
()
Ответ на: комментарий от kostyarin_

Посмотрю сравнение с openssl. Думаю openssl лучше будет т. к. в macos из коробки идет.

volodja-
() автор топика
Ответ на: комментарий от Harald

Да, щас глянул, действительно идет из коробки.

macOS includes a low-level command-line interface to the OpenSSL open-source cryptography toolkit; this interface is not available in iOS.

Although OpenSSL is commonly used in the open source community, it doesn’t provide a stable API from version to version. For this reason, the programmatic interface to OpenSSL is deprecated in macOS and is not provided in iOS. Use of the Apple-provided OpenSSL libraries by apps is strongly discouraged.

To ensure compatibility, if your app depends on OpenSSL, you should compile it yourself and statically link a known version of OpenSSL into your app. Such use works on both iOS and macOS.

In general, however, you should use the CFNetwork API for secure networking and the Certificate, Key, and Trust Services API for cryptographic services. Alternatively, in macOS, you can use the Secure Transport API.

раньше мне попадалось чтото из шифрования в их api, но щас не нашел

volodja-
() автор топика
Последнее исправление: volodja- (всего исправлений: 1)
Ответ на: комментарий от volodja-

вот для macos / ios нашел:

For client code in C, use Core Foundation C networking APIs—part of the CFNetwork framework. The Core Foundation framework and the CFNetwork framework are two of the primary C-language frameworks in OS X and iOS. Together they define the functions and structures upon which the Foundation networking classes are built.

volodja-
() автор топика
Ответ на: комментарий от Harald

ну вот, например, я раскоментил код связанный с openssl, написанный год назад и у он у меня не скомпилился изза того что emum поменялись

volodja-
() автор топика
Ответ на: комментарий от Harald

у меня нет ifdef-ов, просто отдельные .h/.cpp для каждой платформы

volodja-
() автор топика
Ответ на: комментарий от volodja-

ну собери OpenSSL с поддержкой только TLSv1.3. TLS поддерживает всякие там ключи и повторные сессии, а код для разных шифрований чаще всего написан на ассемблере. ты хочешь это всё сам писать?

Iron_Bug ★★★★★
()

Результат выложу в открытый доступ.

ждем…

Deleted
()
Ответ на: комментарий от volodja-

ну так возьми сорцы. но я тебе сразу скажу, что TLSv1.3 - это немалый кусок. это практически половина нынешнего OpenSSL. он распух почти в два раза после его внесения.

Iron_Bug ★★★★★
()
Ответ на: комментарий от stels

в ОС на примере win api или macos CFNetwork framework, в linux это могло бы быть ktls, если бы рукопожатие было реализовано

volodja-
() автор топика
Ответ на: комментарий от volodja-

использовать интерфейсы ядра напрямую в прикладном приложении? Зачем? А после каждого апдейта ядра патчить приложение?

stels ★★★
()
Ответ на: комментарий от volodja-

в ОС на примере win api

В таком ключе - openssl т.к. она является неотъемлемой частью почти любого дистрибутива.

И кстати она кажется умеет TLS offload в ядро.

sergej ★★★★★
()
Ответ на: комментарий от sergej

она кажется умеет TLS offload

https://www.openssl.org/news/cl110.txt

 *) Added the AFALG engine. This is an async capable engine which is able to
     offload work to the Linux kernel. In this initial version it only supports
     AES128-CBC. The kernel must be version 4.1.0 or greater.
sergej ★★★★★
()
Ответ на: комментарий от sergej

похоже что самый стабильный интерфейс в linux дистрах это и есть openssl :)

volodja-
() автор топика
Последнее исправление: volodja- (всего исправлений: 1)

Есть у кого нибудь пример асинхронного C/C++ сокет клиента с использованием openssl ?

volodja-
() автор топика
Последнее исправление: volodja- (всего исправлений: 1)

без openssl/gnussl

оно рассчитано на работу вместе с ними, тебе придётся написать кучу кода, их заменяющих

anonymous
()
Ответ на: комментарий от anonymous

в tlse есть код замены openssl для linux ktls возможно можно было бы оттуда взять минимальную возможную часть, но я там не нашел асинхронных сокетов O_NONBLOCK (чтото типа fcntl(m_socket, F_SETFL … ), вообще искал просто клиент openssl с non-block сокетами но ничего толкового не нашел у меня примерно так получается

06:35:25.316 T 140603351249408 initialize fd 3
06:35:25.910 T 140603351249408 API initialize openssl
06:35:25.913 T 140603351249408 createContext 
06:35:25.913 T 140603351249408 createContext cert/iridium.key cert/iridium.crt
06:35:25.913 T 140603351249408 createSSL 
06:35:25.914 T 140603223705344 wait epoll event code: 4
06:35:25.914 T 140603232098048 handle event: WRITE fd 3
06:35:25.915 T 140603232098048 connectSSL SSL_ERROR_CODE_WANT_READ
06:35:25.915 T 140603232098048 handle event: WRITE fd 3
06:35:25.915 T 140603232098048 connectSSL SSL_ERROR_CODE_WANT_READ
06:35:26.090 T 140603223705344 wait epoll event code: 5
06:35:26.090 T 140603232098048 handle event: READ fd 3
06:35:26.090 T 140603232098048 connectSSL SSL_ERROR_CODE_WANT_READ
06:35:26.091 T 140603232098048 handle event: WRITE fd 3
06:35:26.091 T 140603232098048 connectSSL SSL_ERROR_CODE_WANT_READ
06:35:26.266 T 140603223705344 wait epoll event code: 5
06:35:26.266 T 140603223705344 wait epoll event code: 5
06:35:26.266 T 140603232098048 handle event: READ fd 3
06:35:26.267 T 140603223705344 wait epoll event code: 5
06:35:26.268 T 140603232098048 connectSSL SSL_ERROR_CODE_NONE
06:35:26.268 T 140603232098048 doHandshake SSL_ERROR_CODE_NONE
06:35:26.268 T 140603232098048 read received_size: 0
06:35:26.268 F 140603232098048 worker thread 'client socket listener https://example.com 140603232098048' fatal error, stop thread: openssl reading error: socket was closed by client
volodja-
() автор топика
Последнее исправление: volodja- (всего исправлений: 1)
Ответ на: комментарий от volodja-

Лол, в этом треде прекрасно все.

Ядерный TLS это не для минимизации зависимостей от слова «совсем», это чисто для ускорения. Бери из самых зрелых либ самую удобную и юзай её.

t184256 ★★★★★
()
Ответ на: комментарий от i-rinat

Не учи плохому. Своя реализация TLS — как своя реализация криптографии, первое правило — just don’t. Последнее, что нужно миру и ТСу, это ещё одна дырявая несовместимая реализация TLS.

t184256 ★★★★★
()
Ответ на: комментарий от t184256

в треде изначально шла речь о том чтобы использовать api операионных систем т к они стабильней и быстрей, но с линуксом так не получилось поэтому для линукса будет openssl в котором есть поддержка ktls

volodja-
() автор топика
Последнее исправление: volodja- (всего исправлений: 2)
Ответ на: комментарий от volodja-

т к они стабильней

ну е-мое

но с линуксом так не получилось поэтому для линукса будет openssl в котором есть поддержка ktls

ффух. ну, все хорошо, что хорошо кончается. молодец, Володя.

t184256 ★★★★★
()
16 ноября 2020 г.

Привет, ты говорил что результат выложишь в открытый доступ, если ли он где то, прошу написать тебя мне на почту dvor.nikita420@gmail.com хочу задать пару вопросов

nekish
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.