Задача 19: Секурность

[@ukko]

Давайте угадаю ваш порт… 8080 или 80? :)

[@chernser]

не угадали :)

<?php echo $_SERVER['REMOTE_PORT']; ?> будет выводить какой системный порт был использован на удалённой машине. Если кто то подменит айпи, наврят ли порт совпадет.

На сервере же, для каждого клиента открывается отдельный порт. 80й необходим для принятия запроса на конекшен. В процессе установки соединения с клиентом, сервер открывает еще один порт для него.

[@serega011]

Ну и кто мешает в таком случае перехватить данные о том какой порт, ведь клиент должен узнать свой новый порт, да и вообще говоря затея с портами — гиблая затея. Сразу отсекаются клиенты сидящие за прокси, да и серваку от множества прослушиваемых портов лучше не станет.

[@chernser]

Да — перехватить можно. И метод не панацея.
Для людей седящих за прокси — прокси вроде тоже создает на каждый поток отдельный порт?
Сервер в данном случае ничего прослушивать не будет. Клиентский порт в $_SERVER кладется автоматом.

[@serega011]

На прокси обычно открыто несколько портов и все, остальные данные просто не пройдут.

«Клиентский порт в $_SERVER кладется автоматом.» — угу но это сервер, а клиент то как порт узнает:)

[@merlin-vrn]

Если клиент не за NATом и без проксей, то он знает свой порт ещё до того, как собственно установилось соединение с сервером ;)

Если же соединение не прямое, то клиент свой порт не знает, так же, как и не знает свой «внешний IP». Точнее, порт и IP он знает, но он не знает, с какого именно порта и IP видит сервер.

И может узнать только если сервер ему скажет.

[@serega011]

Угу мы тут говорим про то что соединение устанаввливается, а потом сервак назначает какой-то другой порт для клиента для последующих транзакций. Я понимаю что порт из своего первого запроса клиент знает:)

[@merlin-vrn]

Да никто никакой другой порт не назначает. Сервер всегда использует тот порт, на который соединялся клиент — по умолчанию для http это 80. То есть, во всех пакетах, которые к клиенту (или к прокси) приходят от сервера, стоит порт отправителя 80, и в все пакеты от клиента к серверу направляются на порт 80.

Учите матчасть, то есть, tcp, блин.

И вообще, такой сложный протокол с назначением другого порта не работал бы (или плохо работал бы) через NAT, при наличии файерволла и т. п. Для таких протоколов приходися сильно извращаться (на уровне анализа пакетов TCP), чтобы заработали. Примеры таких FTP, SANE, Amanda протоколов — например, для FTP для обхода этой проблемы изобрели «пассивный режим» и так далее.

[@serega011]

Блин перечитайте то что написано выше, я то понимаю про то что вы пишите и это правильно, но вы не понимаете про то что пишем мы.

[@chernser]

Я тут наверно с неблокирующими сокетами напутал. При их использование принимающий порт остается всегда для приёма, а клиенту алоцируется новый.

[@merlin-vrn]

Совершенно неверно. Сервер принимает соединения на 80-й порт, и никаких «других портов» он не открывает. Для примера, ssh:

tcp 0 0 192.168.1.2:22 192.168.1.34:55692 ESTABLISHED22062/sshd: merlin
tcp 0 0 192.168.1.2:22 192.168.1.34:37659 ESTABLISHED22176/sshd: merlin
tcp 0 160 192.168.1.2:22 88.83.201.253:48613 ESTABLISHED3638/sshd: merlin [

Видно, что на сервере тремя процессами sshd используется порт 22, а различаются они тем, откуда (IP-адрес и порт клиента) приходят и куда уходят пакеты.

HTTP работает также. На сервере используется один порт — тот, который открыли при создании сокета, и всё, никаких дополнительных портов.

[@merlin-vrn]

вот пример с http: процесс apache не связан ни с какими другими портами, кроме 80 и 443:

lsrv d.c # netstat -alnp | grep apache
tcp6 0 0 :::80 :::* LISTEN 1020/apache2
tcp6 0 0 :::443 :::* LISTEN 1020/apache2
tcp6 0 0 192.168.1.2:80 192.168.1.34:47476 ESTABLISHED1020/apache2
tcp6 0 0 192.168.1.2:80 192.168.1.34:47477 ESTABLISHED22542/apache2
tcp6 0 0 192.168.1.2:80 192.168.1.34:47478 ESTABLISHED17684/apache2
tcp6 0 0 192.168.1.2:80 192.168.1.34:47487 ESTABLISHED22510/apache2
tcp6 0 0 192.168.1.2:80 192.168.1.34:47475 ESTABLISHED14516/apache2
tcp6 0 0 192.168.1.2:80 192.168.1.34:47485 ESTABLISHED22527/apache2
tcp6 0 0 192.168.1.2:80 192.168.1.34:47489 ESTABLISHED14520/apache2
tcp6 0 0 192.168.1.2:80 192.168.1.34:47479 ESTABLISHED22486/apache2
tcp6 0 0 192.168.1.2:80 192.168.1.34:47486 ESTABLISHED22060/apache2
tcp6 0 0 192.168.1.2:80 192.168.1.34:47484 ESTABLISHED22622/apache2
tcp6 0 0 192.168.1.2:80 192.168.1.34:47474 ESTABLISHED22502/apache2

[@EiZeRR]

а что нельзя сделать так, чтобы сервак и клиент обменялись ключами, к примеру по протоколу Диффи-Хеллмана и затем при каждом запросе к серваку, сервак будет просить у клиента зашифровать на этом ключе какое-то случайное число и таким образом проверять подлинность клиента.

Кстати, аутенТификация

[@chernser]

Можно, но тогда это уже не моя идея :)

Кстати, спасибо — поправил.

[@FlashXL]

А вы велосипед что ли хотите изобрести?

[@chernser]

Идея появляется только, когда изобретаешь велосипед? ;)
Мне пришла в голову идея — я ей поделился с вами, кто её может оценить.

[@merlin-vrn]

Это называется «SSL».

[@EiZeRR]

не, SSL, это несколько другое — там сертификаты есть, протокол гораздо сложнее.

Тут суть просто примерно одна.

[@merlin-vrn]

Хорошо, это «упрощённый SSL». А протокол там не сложнее, чем вы предложили — такой: обмениваются ключами, проверяют ключи по сертификатам, договариваются об алгоритме симметричного шифрования и выбирают ключ. Причём, это всё происходит прозрачно для приложения на PHP — вообще ни о чём заботиться самому не надо.

[@EiZeRR]

Я знаю, как он выглядит, у меня зачет был по нему:) Ну это вы описали, так сказать, его верхний уровень — обмен сообщениями, а вот если вы посмотрите, как вычисляются ключи и параметры, передаваемые в этих сообщениях, то вы увидите, что там все далеко не просто.

[@merlin-vrn]

Не знаю, по-моему, сама по себе идея аутентификации со схемой Диффи-Хеллмана перебивает сложностью любые вопросы установления сессионного ключа ssl.

Дело даже не в этом. Зачем нужно изобретать велосипед, если есть уже куча работающего софта, который позволяет сделать всё то же самое, не шевельнув ни пальцем? Зачем нужно изобретать «упрощённый SSL», если можно просто воспользоваться полнофункциональным SSL?

[@jeje]

За него на хостинге нужно платить отдельно :)

[@merlin-vrn]

Проекты, которым может потребоваться такая секурность, наверняка способны это оплатить? :)

[@jeje]

Та это еще один пост, сразу в день регистрации, что за народ пошел.

[@merlin-vrn]

Да я видел этот пост в песочнице, заметил. Боюсь обидеть, но не понимаю, за что тут инвайт дали.

[@chernser]

:) просто видимо мне повезло.
Я уже постарался исправиться и написал другой.

[@EiZeRR]

Ну насчет реализации это да — проще воспользоваться готовым решением.
Но вот то что Диффи-Хеллман с двумя посылками с вполне очевидными вычислениями проще, чем SSL с 6 посылками и очень неочевидными вычислениями(там вычисляются три KEY_MATERIAL на основании мастер-ключа, который складывается из двух ключей — открытой и закрытой части, зашифрованной на открытой, которая берется из сертификата сервера; потом на основании этих KEY_MATERIAL получаются два ключа клиента), я не согласен.

[@merlin-vrn]

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

[@etc]

Куки нужно привязывать к IP, хуже от этого не будет. Шанс того, что взломают из-под NAT меньше, чем шанс взлома вообще из всего мира.

[@merlin-vrn]

Если взломают из-под NAT, можно настучать взломщику непосредственно по голове :)

[@JustLuckyGuy]

люди, вы во ssl слышали?!!

[@Busla]

ну, допустим.
А откуда на клиенте узнают «предпологаемый хэш пароля в базе»? Хэширование паролей ведь обычно выполняют с дополнительным ключом ;-)

[@second_pilot]

для пущей безопасности можно пользователю загнать троян и проверять он ли это по другому каналу)

[@crazyprog]

Неее, с портом это как то не надежно! Лучше провести до клиента оптоволокно, поставить аппаратуру и использовать квантовую криптографию.

Ну или просто использовать SSL ;)