The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Релиз ядра Linux 5.1, opennews (ok), 06-Май-19, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


8. "Релиз ядра Linux 5.1"  +2 +/
Сообщение от ффф (?), 06-Май-19, 10:54 
>Во встроенную релизацию протокола TLS

- зачем оно там? и зачем тогда опен/либра_ssl?

Ответить | Правка | Наверх | Cообщить модератору

11. Скрыто модератором  –5 +/
Сообщение от Штирлиц (?), 06-Май-19, 11:09 
Ответить | Правка | Наверх | Cообщить модератору

15. Скрыто модератором  +1 +/
Сообщение от А (??), 06-Май-19, 11:23 
Ответить | Правка | Наверх | Cообщить модератору

21. Скрыто модератором  +/
Сообщение от Аноним (21), 06-Май-19, 11:46 
Ответить | Правка | Наверх | Cообщить модератору

24. Скрыто модератором  +6 +/
Сообщение от Аноним (24), 06-Май-19, 11:54 
Ответить | Правка | Наверх | Cообщить модератору

81. Скрыто модератором  +/
Сообщение от Аноним (81), 06-Май-19, 23:30 
Ответить | Правка | Наверх | Cообщить модератору

83. Скрыто модератором  +7 +/
Сообщение от Led (ok), 07-Май-19, 00:35 
Ответить | Правка | Наверх | Cообщить модератору

17. "Релиз ядра Linux 5.1"  +5 +/
Сообщение от zanswer CCNA RS and S (?), 06-Май-19, 11:36 
«The idea is for the kernel to handle the symmetric encryption and decryption, while leaving the handshake processing to user space. The feature uses the user-space API to the kernel's crypto subsystem, which is accessed via sockets created using the AF_ALG address family.»

https://lwn.net/Articles/666509/

Суть идеи в том, что таким образом выполняется offloading функций Record Layer TLS, он отвечает за передачу фактических данных, всё остальное остаётся в userspace, более того libressl и openssl взаимодействуют с KTLS.  

Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

37. "Релиз ядра Linux 5.1"  –4 +/
Сообщение от КО (?), 06-Май-19, 13:21 
>Суть идеи в том, что

теперь при атаке человек по средине, если кто-то додумается отправить в ответ 4T пакет, то упадет не Ваш любимый Appache/Nginx/Chrome/FF/нужное подставить, а сразу йадро.

Ответить | Правка | Наверх | Cообщить модератору

46. "Релиз ядра Linux 5.1"  +/
Сообщение от Аноним (24), 06-Май-19, 15:06 
Поле Total Length в заголовке IP имеет размер, всего лишь, 16 бит, если что.
Ответить | Правка | Наверх | Cообщить модератору

55. "Релиз ядра Linux 5.1"  +/
Сообщение от Аноним (55), 06-Май-19, 16:22 
Голословное утверждение
Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

92. "Релиз ядра Linux 5.1"  +6 +/
Сообщение от zanswer CCNA RS and S (?), 07-Май-19, 09:33 
Вы ошибаетесь, когда думаете, что для ядра есть разница, какой размер имеют передаваемые данные между приложениями.

RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 содержит исчерпывающие требования к реализации TLS протокола и в частности Record Layer:

«5.  Record Protocol
The TLS record protocol takes messages to be transmitted, fragments the data into manageable blocks, protects the records, and transmits the result.  Received data is verified, decrypted, reassembled, and then delivered to higher-level clients.

TLS records are typed, which allows multiple higher-level protocols to be multiplexed over the same record layer. This document specifies four content types: handshake, application_data, alert, and change_cipher_spec.
~~~
5.1.  Record Layer
The record layer fragments information blocks into TLSPlaintext records carrying data in chunks of 2^14 bytes or less. Message boundaries are handled differently depending on the underlying ContentType. Any future content types MUST specify appropriate rules.
~~~
Application Data messages contain data that is opaque to TLS. Application Data messages are always protected.  Zero-length fragments of Application Data MAY be sent, as they are potentially useful as a traffic analysis countermeasure.  Application Data fragments MAY be split across multiple records or coalesced into a single record.
~~~
enum {
          invalid(0),
          change_cipher_spec(20),
          alert(21),
          handshake(22),
          application_data(23),
          (255)
      } ContentType;

struct {
          ContentType type;
          ProtocolVersion legacy_record_version;
          uint16 length;
          opaque fragment[TLSPlaintext.length];
      } TLSPlaintext;

type:  The higher-level protocol used to process the enclosed fragment.
~~~
length:  The length (in bytes) of the following TLSPlaintext.fragment. The length MUST NOT exceed 2^14 bytes. An endpoint that receives a record that exceeds this length MUST terminate the connection with a "record_overflow" alert.

fragment:  The data being transmitted. This value is transparent and is treated as an independent block to be dealt with by the higher-level protocol specified by the type field.»

С точки зрения KTLS нет не какой разницы где начинается или заканчивается конкретное сообщение вышестоящего протокола, например HTTP. Ядро лишь разделает поток байт на блоки размером не превышающем 2^14, при превышении соединение разрывается; выполняет над ними криптографические операции и передаёт далее по стеку для отправки через сеть. Когда ядро получает данные по стеку, то выполняет над полученными данными криптографические операции, после чего объединяет полученные блоки в последовательный поток байт, снова не заботясь не о каких границах сообщений, вышестоящего протокола.

Поскольку в классическом случае TLS работает поверх TCP, то ему нет не какой нужды заботиться о порядке получения блоков или их количестве. С точки зрения TLS, всё блоки получены в том порядке и в том количестве, котором они были сформированными на передающей стороне. И теперь нужно лишь снова их преобразовать в последовательный поток байт, который прочитает наше приложение, например Apache.

P/S/ Если у кого-то есть замечания или указания на ошибки в изложенном, буду рад комментариям. :)

Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

52. "Релиз ядра Linux 5.1"  –3 +/
Сообщение от Имя (?), 06-Май-19, 15:45 
облегчить работу скомпрометированному ядру
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

58. "Релиз ядра Linux 5.1"  +/
Сообщение от Аноним (55), 06-Май-19, 16:30 
Скомпрометированное ядро и так имеет доступ к памяти всех пользовательских процессов
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру