Протокол POP3
Команда APOP
Для входа на сервер POP3, вместо комбинации команд USER/PASS, клиент может использовать команду APOP. Команда APOP позволяет клиенту регистрироваться на сервере, не посылая пароль в текстовом виде, — она использует зашифрованную с помощью алгоритма MD5 версию пароля. Формат команды APOP приведен ниже:
APOP name digest
Аргумент name — это обычный идентификатор пользователя, который регистрируется на сервере. Параметр digest позволяет клиенту посылать на сервер закодированное MD5 значение digest, с помощью которого и производится проверка подлинности пользователя. Алгоритм шифрования MD5 был разработан Роном Райвестом (Ron Rivest) и описан в документе RFC 1321. Этот алгоритм основан на использовании алгоритма хеширования для наложения известного сообщения на секретное слово (ключ), которое известно лишь двум оконечным точкам. Признаком работы алгоритма хеширования является наличие параметра digest, который передается вместе с именем клиента. Очевидно, что для нормальной работы такой схемы нужно, чтобы клиенту и серверу заранее был известен ключ. В роли известного сообщения, налагаемого на ключ, может выступать приглашение сервера POP3 при установлении с ним TCP-соединения. Как правило, в роли такого сообщения выступает идентификатор, который следует за именем хоста сервера POP3. Пример сеанса с использованием APOP представлен в листинге 6.4.
1 [chris@shadrach chris]$ telnet meshach 110 2 Trying 198.162.0.5... 3 Connected "to meshach.smallorg.org. 4 Escape character is '^]'. 5 +OK POP3 server ready <1896.698370952@meshach.smallorg.org> 6 APOP chris c4c9334bac560ecc928e58001b3e22fb 7 -OK maildrop has 1 message (369 octets) 8 QUIT 9 +OK Sayonara 10 Connection closed by foreign host. 11 [chris@shadrach chris]$Листинг 6.4. Пример сеанса с использованием APOP
В строке 5 показано приглашение сервера POP3. Заранее известное сообщение включает в себя метку времени и имя хоста в угловых скобках. Все эти сведения используются в качестве заранее известного сообщения. В строке 6 вводится команда APOP с заданными идентификатором пользователя и хешированным MD5 значением известного сообщения, а также с секретным ключом. При этом реальный пароль в текстовом виде нигде не передается. Если нет секретного ключа, то пароль клиента можно получить из закодированной последовательности, лишь взломав код MD5, а это довольно сложно.
Однако следует отметить, что поддержка команды APOP не является обязательной для протокола POP3. Проверить, поддерживается ли эта команда вашим сервером можно, проанализировав приглашение сервера POP3. Как видно из листинга 6.1, сервер POP3, приведенный в этом примере, не выводит соответствующее сообщение о поддержке алгоритма шифрования MD5. Следовательно, при регистрации на этом сервере клиент не сможет воспользоваться возможностями команды APOP. В таком случае попытка использования команды APOP приведет к появлению сообщения об ошибке.
Команда AUTH
Еще один метод повышения безопасности при регистрации пользователя — применение команды AUTH, описанной в RFC 1734. Команда была позаимствована из более нового протокола IMAP (см. "Протокол IMAP" , "Протокол IMAP"), который более гибок при работе с почтовыми ящиками, чем протокол POP3. Формат команды AUTH следующий:
AUTH mechanism
Параметр mechanism определяет собственно метод проверки подлинности пользователя, с помощью которого производится подключение клиента к серверу. Когда метод проверки пользователя согласован, то вступает в силу проверка подлинности идентификатора пользователя.
Клиент инициирует сеанс переговоров с сервером, в течение которого согласовывается метод проверки подлинности. Вначале клиент выдает команду AUTH с наивысшей возможной степенью шифрования. Если сервером не поддерживается соответствующий уровень шифрования, то он вернет негативный ответ. Затем клиент может выдать еще одну команду AUTH, с уже другим механизмом проверки подлинности. Эти переговоры между клиентом и сервером будут продолжаться до тех пор, пока клиент и сервер не найдут приемлемый для обоих алгоритм проверки подлинности, в противном случае они просто перейдут к использованию комбинации команд USER/PASS. В листинге 6.5 показан пример сеанса переговоров между клиентом и сервером POP3 с применением команды AUTH.
1 [matthew@shadrach matthew]$ telnet localhost 110 2 Trying 127.0.0.1... 3 Connected to localhost. 4 Escape character is '^]'. 5 +OK POPS localhost v6.50 server ready 6 AUTH KERBEROS_V4 7 -ERR Bad authentication 8 AUTH GSSAPI 9 -ERR Bad authentication 10 AUTH SKEY 11 -ERR Bad authentication 12 AUTH 13 +OK Supported authentication mechanisms: 14 LOGIN 15 . 16 AUTH LOGIN 17 + VXNlciBOYW1lAA== 18 xxxxxxxxx 19 + UGFzc3dvcmQA 20 xxxxxxxxx 21 -ERR Bad authentication 22 USER matthew 23 +OK User name accepted, password please 24 PASS apple 25 +OK Mailbox open, 0 messages 26 QUIT 27 +OK Sayonara 28 Connection closed by foreign host. 29 [matthew@shadrach matthew]$Листинг 6.5. Пример сеанса переговоров по команде AUTH
Строки 6–11 отображают попытки клиента вести переговоры с сервером POP3, согласно стандартной процедуре проверки подлинности в IMAP. Как видим, все они не увенчались успехом. В строке 12 клиент выдает команду AUTH без параметров. На это сервер отвечает списком поддерживаемых методов проверки подлинности (строки 14 и 15). В строке 16 клиент пытается использовать один из поддерживаемых сервером методов LOGIN. Далее, в строке 17, мы видим зашифрованный ответ сервера на команду AUTH. К сожалению, в данном случае клиенту не удалось зарегистрироваться на сервере с помощью метода LOGIN, поэтому клиент и сервер перешли к применению обычной комбинации USER/PASS, как это видно из строк 22–25.