Nets2010 (1131259), страница 56

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 56)

7.4.4. Передача сообщений

Основная задача системы передачи почтовых сообщений – надежно доставить сообщение от отправителя к получателю. Самый простой способ сделать это – установить транспортное соединение и по нему передавать почту.

7.4.4.1. SMTP (Simple Mail Transfer Protocol) – Простой протокол передачи почты

В Internet почта передается следующим образом. Машина отправитель устанавливает ТСР-соединение с 25-м портом машины получателя. На 25 порту находится почтовый демон, который работает по протоколу SMTP. Он принимает соединение и распределяет поступающие сообщения по почтовым ящикам машины-получателя.

SMTP - это простой ASCII-протокол. После установления соединения машина-отправитель работает как клиент, а машина-получатель – как сервер. Сервер шлет текстовую строку, идентифицирующую его и готовность принимать почту. Если он не готов принимать почту, то клиент разрывает соединение и повторяет всю процедуру позже.

Если сервер подтвердил свою готовность, то клиент сообщает, от кого и кому предназначено очередное сообщение. Если сервер подтвердил наличие получателя, то он дает команду клиенту, и сообщение передается без контрольных сумм и подтверждений, так как ТСР-соединение обеспечивает надежный поток байтов. Если сообщений несколько, то все они передаются. Обмен по соединению происходит в обоих направлениях.

Замечание. Клиент всегда посылает 4-символьные команды. Команды сервера в основном цифровые.

У SMTP протокола, несмотря на то что он хорошо описан в RFC 821, есть несколько проблем. Первая – длина сообщения не может превосходить 64 Кбайт. Другая – time out. Если время ожидания подтверждения у отправителя и получателя не согласовано, то один будет разрывать соединение, не дождавшись, тогда как другой просто очень загружен. Третья – почтовый ураган. Пусть машина-получатель имеет лист рассылки, где указана машина-отправитель, и наоборот. Тогда отправка сообщения по листу рассылки вызовет бесконечно долгие обмены сообщениями между этими машинами.

Для преодоления этих проблем в RFC 1425 был описан протокол ESMTP. Клиент вначале шлет команду EHLO, если она отвергается сервером, то это означает, что сервер работает по SMTP.

7.4.4.2. Почтовые шлюзы

Протокол SMTP хорош, когда обе машины находятся в Internet. Однако это не всегда так. Многие компании в целях сетевой защиты соединяют свои сети через надлежащие средства, либо используют другие протоколы. Например, отправитель или получатель могут использовать протокол Х.400. Такая ситуация показана на рисунке 7-55. Отправитель передает сообщение шлюзу, тот его буферизует и позднее передает получателю. Звучит просто, но на деле все сложнее.

Рисунок 7-55. Передача электронного письма с использованием почтового шлюза на прикладном уровне

Первая проблема – соответствие адресов. Вторая – соответствие конвертов и заголовков. Третья – соответствие тела сообщения. Например, в случае, если тело содержит аудиофайл, а на стороне получателя с ним работать не умеют. Или отправитель поставил следующее условие: если передача сообщения не пройдет по почтовому соединению, то нужно повторить его по факсу, а получатель не умеет работать с факсом. Однако для простых неструктурированных ASCII-сообщений SMTP-шлюз – решение проблемы.

7.4.4.3. Доставка получателю

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

Как это происходит? Простой протокол для изъятия почты из удаленного почтового ящика – РОР3. Он позволяет входить в удаленную систему и выходить из нее.. Главное - он позволяет забирать почту с сервера и хранить ее на машине пользователя.

Более сложный протокол IMAP – Interactive Mail Access Protocol. Он позволяет одному и тому же пользователю заходить с разных машин на сервер, чтобы прочесть или отправить почту. Это по существу удаленное хранилище писем. Он, например, позволяет получать доступ к письму не только по его номеру, но и по содержанию.

Третий часто используемый протокол – DMSP (Distributed Mail System Protocol RFC 1056). Этот протокол не предполагает, что пользователь работает все время с одной и той же почтовой службой. Пользователь может обратиться к серверу и забрать почту на свою локальную машину, после чего разорвать соединение. Обработав почту, он может ее отправить позже, когда будет установлено очередное соединение.

Важными почтовыми сервисами являются:

• Фильтры

• Пересылка поступающей почты на другие адреса

• Демон отсутствия

• Почтовый робот (программа, анализирующая входящие письма и отвечающая на них)

7.4.5. Конфиденциальность почты

Пославший почту, естественно, предполагает, что ее никто не читает кроме адресата. Однако если об этом специально не позаботиться, то гарантировать этого нельзя. Далее мы рассмотрим две широко распространенных безопасных почтовых системы - PGP и PEM.

7.4.5.1. PGP – Pretty Good Privacy

PGP – дословно: «вполне хорошая конфиденциальность» – разработка одного человека - Фила Зиммермана. Это полный пакет безопасности, который включает средства конфиденциальности, установления подлинности, электронной подписи, сжатия, и все это в удобной для использования форме. Благодаря тому, что это разработка далекого от государственных структур человека, качественная, работает как на платформе Unix, так и MS-DOS/Windows, Macintosh и распространяется бесплатно, она получила очень широкое распространение.

PGP использует алгоритмы шифрования RSA, IDEA и MD5. PGP поддерживает компрессию передаваемых данных их секретность, электронную подпись и средства управления доступом к ключам. Схема работы PGP показана на рисунке 7-56. На этом рисунке DA, DB - личные (закрытые) ключи А и В соответственно, а EA, EB – их открытые ключи. Отметим, что секретный ключ для IDEA строится автоматически в ходе работы PGP на стороне А и называется ключом сессии - KM, который затем шифруется алгоритмом RSA с открытым ключом пользователя В. Также следует обратить внимание на то, что медленный алгоритм RSA используется для шифрования коротких фрагментов текста: 128-разрядного ключа для MD5 и 128-разрядного ключа для IDEA.

Рисунок 7-56. Действия PGP при отправке сообщения

PGP поддерживает три длины ключей:

• Обычный – 314 бит (может быть раскрыт за счет больших затрат).

• Коммерческий – 512 бит (может быть раскрыт специализированными организациями ЦРУ, АНБ, ФСБ, МВД, ФБР).

• Военный – 1024 бита (не может быть раскрыт пока никем на Земле).

Формат PGP-сообщения показан на рисунке 7-57.

Рисунок 7-57. Формат PGP-сообщения

7.4.5.2. PEM – почтовая служба с повышенной конфиденциальностью

PEM имеет статус Internet-стандарта (RFC 1421, 1424). Сообщения, пересылаемые с помощью PEM, сначала преобразуются в каноническую форму. В этой форме соблюдены соглашения относительно спецсимволов типа табуляции, последовательных пробелов и т.п. Затем сообщение обрабатывается MD5 или MD2, шифруется с помощью DES (56-разрядный ключ) и передается с помощью кодировки base64. Передаваемый ключ защищается либо с помощью RSA, либо с помощью DES по схеме EDE.

В таблице 7-58 дано сравнение почтовой системы PEM и PGM.

Таблица 7-58. Сравнение PGM и PEM

66. Служба FTP: организация, протокол.

7.5. Протокол передачи файлов - FTP

FTP (File Transfer Protocol, Протокол передачи данных) - это один из первых и все еще широко используемых интернет-сервисов.

Протокол FTP предназначен для решения следующих задач:

• разделение доступа к файлам на удаленных абонентских машинах

• прямое или косвенное использования ресурсов удаленных компьютеров

• обеспечение независимости клиента от файловых систем удаленных абонентских машин

• эффективная и надежная передача данных

FTP - это протокол прикладного уровня, который, как правило, использует в качестве транспортного протокола TCP. FTP не может использоваться для передачи конфиденциальных данных, поскольку не обеспечивает защиты передаваемой информации и передает между сервером и клиентом открытый текст. FTP-сервер может потребовать от FTP-клиента аутентификации (т.е. при подсоединении к серверу FTP-пользователь должен будет ввести свой идентификатор и пароль). Однако и пароль, и идентификатор пользователь будут переданы от клиента на сервер открытым текстом.

7.5.1. Модель работы FTP

Простейшая модель работы протокола FTP представлена на рисунке 7-59, где введены следующие обозначения:

• «User Interface» - пользовательский интерфейс работы с FTP.

• «User-PI» - интерпретатор команд пользователя (User Protocol Interpretator). Этот объект взаимодействует с «Server-PI», чтобы обмениваться командами управления передачей данных по каналу передачи команд и с «User-DTP» - модулем, который осуществляет непосредственную передачу данных по каналу передачи данных.

• «User-DTP» - модуль, осуществляющий обмен данными (User Data Transfer Process) между клиентом и сервером FTP по каналу передачи данных на основании команд модуля «User-PI». Этот объект взаимодействует с файловой системой пользователя и объектом «Server-DTP».

• «Server-PI» - модуль управления обменом данных со стороны сервера (Server Protocol Interpretator) по каналу передачи команд.

• «Server-DTP» - модуль, осуществляющий обмен данными со стороны сервера (Server Data Transfer Process) по каналу передачи данных

• «Сервер FTP» - модуль, осуществляющий работу FTP-сервера. Он состоит из модуля управления передачей - «Server-PI» и модуля, осуществляющего передачу, - «Server-DTP».

• «Пользователь FTP» - модуль клиента FTP. Он состоит из модуля управления передачей - «User-PI» - и модуля, осуществляющего передачу - «User-DTP».

Рисунок 7-59. Модель работы протокола FTP

FTP поддерживает сразу два канала соединения - канал передачи команд (и статусов их обработки) и канал передачи данных. Канал передачи данных может использоваться для передачи как в одном, так и в другом направлении, кроме того, он может закрываться и открываться по командам управляющих модулей в процессе работы. Канал передачи команд открывается с установлением соединения и используется только для передачи команд и ответов их обработки.

Алгоритм работы протокола FTP состоит в следующем:

1. Сервер FTP использует в качестве управляющего соединение на TCP порт 21, который всегда находится в состоянии ожидания соединения со стороны FTP-клиента.

2. После того как устанавливается управляющее соединение модуля «User-PI» с модулем сервера - «Server-PI», клиент может отправлять на сервер команды. FTP-команды определяют параметры соединения передачи: роли участников соединения (активный или пассивный), порт соединения (как для «User-DTP», так и для «Server-DTP»), тип передачи, тип передаваемых данных, структуру данных и управляющие директивы, обозначающие действия, которые пользователь хочет совершить, например, сохранить, считать, добавить или удалить данные или файл.

3. После того как согласованы все параметры канала передачи данных, один из участников соединения, который является пассивным (например, клиентский модуль «User-DTP»), становится в режим ожидания открытия соединения на заданный для передачи данных порт. После этого активный модуль (например, «Server-DTP») открывает соединение и начинает передачу данных.

4. После окончания передачи данных соединение между «Server-DTP» и «User-DTP» закрывается, но управляющее соединение «Server-PI» - «User-PI» остается открытым. Пользователь, не закрывая сессии FTP, может еще раз открыть канал передачи данных, передать необходимую информацию и т.д.

FTP может использоваться не только при передаче файлов между клиентом и сервером, но и между двумя FTP-серверами, ни один из которых не расположен на локальном хосте пользователя.

Характеристики

Список файлов ответов (шпаргалок)