[/b/] [/d/] [/tu/] [/a/] [/ph/] [/wa/] [/cg/] [/t/] [/p/]

[Burichan] [Foliant] [Futaba] [Greenhell] [Gurochan] [Photon] - [Home] [Manage] [Archive]

[Return]
Posting mode: Reply
Leave these fields empty (spam trap):
Name
Link
Subject
Comment
File
Verification
Password (for post and file deletion)
  • Supported file types are: GIF, JPG, PDF, PNG
  • Maximum file size allowed is 20480 KB.
  • Images greater than 200x200 pixels will be thumbnailed.

File: 1511790482588.png -(15255 B, 200x77) Thumbnail displayed, click image for full size.
15255 No.146645  

Привет, новерь. У меня несколько вопросов по протоколу TLS.

  1. Что происходит после TLS handshake?
  2. Разделяются ли передаваемые данные на блоки (порции), сохраняется ли их последовательность?
  3. Целостность данных проверяется для каждого блока/сообщения отдельно?
  4. Почему в TLS обязательно использование сертификатов? Как без них обходятся альтернативные протоколы (например, Enigform на клиенте + Apache mod_openpgp на сервере)?
  5. Почему согласование алгоритмов шифрования происходит после, а не до отправки сертификата?
>> No.146646  
File: 1511794857290.jpg -(344772 B, 1200x1200) Thumbnail displayed, click image for full size.
344772

>>146645
1. Обмен данными
2. Да, да
3. Да, как минимум на уровне tcp
4. Чтобы исключить mitm-атаку
5. В 1.3 это исправили

>> No.146653  

>>146646
6. Осталась ли возможность подмены сертификатов в 1.3?
7. Допустим, MITM будет выдавать себя за сервер с TLS 1.2 и подсунет другой сертификат. Что тогда?
8. Что делать, если петушня запретит TLS 1.3 и будет проделывать пункт 7 со всеми сайтами? Дожидаться, пока браузеры перестанут поддерживать 1.2, слишком долго.

>> No.146654  
File: 1511801117637.jpg -(323106 B, 1210x800) Thumbnail displayed, click image for full size.
323106

>>146653
6. В той же степени что и в 1.2. Это решает проблему скрытия целевого домена но никак не подмены.
7. Если он не будет подписан валидным для клиента CA то его сертификат просто не пройдет проверку. (Если конечно клиент вообще валидирует сертификаты а не принимает все сертификаты подряд).
8. Единственная утечка в 1.2 это целевой домен.

>> No.146657  

Самый понятный ман по ТЛС, что я читал.

>> No.146659  

Такой вопрос (возможно, связанный). У меня есть старый телефон на андроиде 2.1. Недавно разбил свой новый и пришлось достатть старый с полки. Оказалось, что на старом телефоне, где уже давно ничего не обновляется, не открываются практически никакие https страницы (а сейчас большинство сайтов на https, даже те, где, казалось бы, и не особо надо). Это как-то связано с тем, что клиент не поддерживает новые версии https/tls? Чинить не собираюсь, просто интересно.

>> No.146661  
File: 1511812205054.png -(309029 B, 670x600) Thumbnail displayed, click image for full size.
309029

>>146659

> Это как-то связано с тем, что клиент не поддерживает новые версии https/tls? Чинить не собираюсь, просто интересно.

TLS 1.2 релизнулся в 2008, андроид 2.1 вышел в 2009, так что скорее всего он его поддреживает. Тут более вероятна неправильно выставленная дата, из-за чего не проходят проверку сертификаты сайтов.

>> No.146665  

Подходящий тред, давно хотел спросить.
Я вот понял, что не понимаю.
Берём броузер, заходим на сайт.
Потом берём netstat, видим открытую сессию с сайтом.
Если брать реализацию tcp/IP, а не osi, то уровень сессий это application layer.
Т.е. это получается, что ос запросила не свой сетевой стек, а броузер на предмет сессий?

>> No.146666  

>>146659
Сертификаты СА асоритис устарели.
В виндоус они обновляются вместе с системой.
Вручную обновить конечно можно. .. Кстати, идея для приложения.

>> No.146667  

>>146665

Эта ваша OSI из страны единорогов, от реального мира оторвана. Чтобы знать, какому процессу следует посылать пакеты, приходящие с addr1:port1 на addr2:port2, ядру нужно где-то эту инфу хранить. Можно это называть сессией (потому что это как бы и есть сессия), но в документации используется термин connection. Даже тот же UDP, и для него создаётся «сессия» на уровне ядра (можешь посмотреть при помощи `ss -u`), хотя протокол типа connectionless. Ядру нужно знать, какой процесс послал UDP-пакет, чтобы посылать этому процессу ответы.

И вообще, переходи на ss. Он и расово более корректен, и печатать проще, да и утилиты из iproute2 позиционируются как замена legacy из net-tools.

>> No.146670  

>>146667
1) Ну я как-бы про про реализацию стеков и про их модель и говорю, не про osi модель.
2) В сессию нужно включать стейт. Т.е. это и сиквенсы и метки пакета, завроде syn, а в случае стейтлис удп к этому ещё и ицмп ответы можно отнести. Может я что-то забыл. Например, windowing буферы стека для транспорта, это можно как к параметру сессии отнести, т.к. от сиквенсов отделимо плохо, а можно считать чистым транспортом.
3) В принципе ты прав, мой вопрос можно переиначить - так что-же всё-таки нужно называть сессией? У меня конкретно затруднение именно с тем, что я описал. Есть браузер, есть нетстат. Броузер создаёт сессию. Все что я помню, относящееся к сессии, не выходит за пределы транспорта. Может я какого-то большого куска не знаю? Зачем тогда сессию в модели tcp/IP (не osi) выносят в аппликэйшен лейр?
Т.е. понятно, что есть всякие вещи, типа Скайпа, где кветирование идёт уже выше, на уровне самого приложения, а не в удп, но таких прикладных приложений меньше. Понятно, что все это некоторого рода условность. Но должна же быть какая-то сакраментальная мысль, почему сессии отнесли в апликэйшн в описании модели tcp/IP!
Потом про нетстат, я как-то раньше не думал, а действительно, откуда он берет состояние? Пишет - connected, очевидно он не син/акк в буфере слушает. Т.е. само приложение, когда запрашивает у ядра конекшн, потом передает ядру стейт? Скажем, откуда ядру знать, что происходит у тфтп? Оно может принять данные в буфер и выкинуть в канал. Может - эй, тфтп, вот на твой порт что-то привалило. А нетстат напишет - вот вам коннектед тфтп сессия.
4) Я в линуксе только sip траблшутаю иногда, обычно виндоус, но спасибо.

>> No.146673  
File: 1511862030726.jpg -(392046 B, 900x900) Thumbnail displayed, click image for full size.
392046

>>146670
netstat отображает tcp соединения, которые с пользовательской сессией на сайте соотносятся слабо. Сам по себе http протокол stateless и представляет собой последовательность запросов и ответов на них. Изначально на каждый запрос устанавливалось новое соединения и после ответа сервер его закрывал (http/1.0), потом для ускорения процесса начали переиспользовать соединения (http/1.1) и сравнительно недавно появилось мультиплексирование (http/2), впрочем последний пока еще мало распространен. Но во всех случаях каждый запрос - отдельная сущность и не имеет значения, пришел он с новым соединением или был отправлен в уже существующее. Для того чтобы отличать одного клиента от другого чаще всего используются cookies, которые клиент передает в соответствующем поле в каждом из своих запросов. Более экзотические способы - http auth, когда в каждом запросе клиент передает логин и пароль, и дописывание идентификатора во все url. Это так же позволяет для экономии ресурсов не держать постоянно открытые соединения, менять ip во время работы, продолжать сессию даже после перезагрузки компьютера.

>> No.146674  

>>146654
Допустим, петушня сделает так, что ты либо установишь MITM-сертификат, либо не попадаешь на свой любимый сайтик. Трафик шифруется на поддельный сертификат и они в принципе могут его расшифровать, ведь так?
Почему в TLS 1.3 от этого нет защиты?

>> No.146675  

>>146674
Имхо, это шире назначения протокола. Ты можешь не принимать сертификат? Можешь. К протоколу вопрос снят. Решение выходит за рамки тлс.

>> No.146677  

>>146674
Потому что защита от этого в принципе невозможна. Enigform + mod_openpgp тоже не представляют такой защиты. Если твоя первая связь с сайтом происходит по скомпрометированному каналу (активный MitM и доверие сертификатам, которым не следует доверять) и ты продолжишь использовать этот же канал, то тебя ничто не защитит от MitM.

>> No.146680  

>>146673
Да, точно.
Спасибо, хорошо направил.
Приложение запрашивает сокет и транспорт. Внутри транспорта может существовать сессия.
Но помимо того, сессия может быть ещё средствами самого приложения. Кипэлайфы самые разные, которые к транспорту никак не относятся. От броузера к вэб сервису, эмуляция кейстроуков в ссш, хеллоу тех роутинговых протоколов, которые поверх транспорта. И в модели tcp/IP в аппликэйшен относят как раз это. Т.е. пэйлоад до сокета.
Это как раз объясняет почему при аварийном завершении приложения закрывается соединение. Ведь дать команду на завершение транспортной сессии приложение не могло. Но зато ос, закрывая сокет, автоматом выполнило работу с сетевым стеком.
Или, например, нетстат как раз должен смотреть сокеты, т.е. ему глубоко положить что на самом деле происходит в сети, или в драйвере интерфейса. Утилита показывает не что происходит с точки зрения сетевого стека, а что прикладной уровень запросил у ядра. .. Надо будет про эту интерфейсную связку подробнее читнуть.



Delete Post []
Password

[/b/] [/d/] [/tu/] [/a/] [/ph/] [/wa/] [/cg/] [/t/] [/p/]