Проверка птс на подлинность: Как проверить ПТС на подлинность перед покупкой автомобиля

Содержание

Как проверить ПТС на подлинность онлайн?

Любого покупателя бывшей в употреблении машины интересует вопрос: есть ли какие-то простые способы проверить паспорт транспортного средства в онлайн режиме на подлинность? То есть, есть ли такие сайты, где можно было бы ввести номер и серию ПТС и система вам выдаст всю нужную информацию:

  • реальная дата производства;
  • нет ли ограничений по кредитам или за неуплату штрафов;
  • не является ли данный автомобиль угнанным;
  • не попадал ли он раньше в ДТП.?

Ответим сразу — такого сайта нет. Разберемся с вопросом более детально.

Официальный сайт ГИБДД

Мы уже ранее писали на Vodi.su, что у ГИБДД появился в 2013 году свой собственный сайт, предоставляющий некоторые услуги в режиме онлайн совершенно бесплатно:

  • проверка истории регистрации в ГИБДД;
  • проверка на участие в ДТП;
  • проверка нахождения в розыске;
  • информация об ограничениях и залогах;
  • информация об оформлении ОСАГО.

Также есть сервис для проверки самого владельца транспортного средства — реально ли ему выдавались права и какие штрафы числятся за человеком.

Для получения всех этих данных вам нужно ввести 17-значный ВИН-код, номер шасси или кузова. Проверить ВУ на подлинность можно по его номеру и дате выдачи. Задолженность по штрафам проверяют по регистрационным номерам ТС или по номеру свидетельства о регистрации. Форма же для ввода номера ПТС отсутствует. Соответственно, проверить данный документ через официальный веб ресурс Госавтоинспекции невозможно.

Какие сведения об авто выдаст сайт ГИБДД?

Если ввести VIN-код, то система выдаст вам следующую информацию об автомобиле:

  • марка и модель;
  • год выпуска;
  • ВИН, номера кузова и шасси;
  • цвет;
  • мощность двигателя;
  • тип кузова.

Помимо этого будут показаны периоды регистрации и собственник — физическое или юридическое лицо. Если авто не попадало в ДТП, не числится в розыске или в реестре залоговых транспортных средств, то об этом также будет указано, вам лишь нужно будет ввести капчу из цифр.

Все полученные сведения можно сверить с теми, которые записаны в ПТС. Если же система выдает ответ, что по данному VIN-коду сведения отсутствуют, — это повод забеспокоиться, так как любое авто, зарегистрированное на территории России, вносится в базы ГИБДД. То есть, если владелец вам показывает паспорт, но по ВИН-коду проверка не дает результатов, значит, скорее всего, вы имеете дело с мошенниками.

Другие сервисы для сверки

VINFormer — это онлайн сервис для проверки транспортных средств. Здесь тоже нужно вводить именно ВИН-код. В бесплатном режиме можно получить лишь данные о самой модели: объем двигателя, начало производства, в какой стране собрана и пр. Полная же проверка обойдется в 3 евро, при этом вы получите информацию о возможных угонах, ДТП, ограничениях.

По такому же принципу работает и другой сервис — AvtoStat. В нем можно проверить авто пригнанные в Россию из Европы, США и Канады. В бесплатном отчете содержится информация лишь о модели. Оплатив же 3 доллара через интернет-кошелек или банковскую карту, вы узнаете всю историю интересующего вас транспортного средства:

  • страна происхождения;
  • сколько владельцев было;
  • даты прохождения ТО и диагностики;
  • разыскивается ли в США, Канаде, Румынии, Словении, Италии, Чехии, Словакии, России;
  • фото отчет — если машину продавали с аукциона;
  • заводская комплектация на момент первой продажи в салоне.

То есть, если вы покупаете авто, пригнанное из-за границы, можете добавить данные два сервиса в закладки.

Есть и другие менее популярные онлайн сервисы, но они все подключены к базам данных ГИБДД, Carfax, Autocheck, Mobile.de, так что какие-то принципиально новые сведения о машине б/у на них вы вряд ли найдете.

Подлинность ПТС

Как видим, сервиса для проверки по номеру ПТС нет. При покупке б/у автомобиля обязательно сверьте полученную с сайтов информацию с той, которая указана в ПТС:

  • VIN-код;
  • технические характеристики;
  • цвет;
  • периоды регистрации;
  • номера шасси и кузова.

Все они должны совпадать. Если имеются на самом бланке особые отметки, например «дубликат», нужно более подробно расспросить продавца. Обычно большинство покупателей отказываются от покупки авто по дубликату, но его могут выдавать в случае банальной утери паспорта или его порчи. Кроме того, если машина часто меняла владельцев, в ГИБДД должны выписать дополнительный бланк, оригинал при этом тоже остается у последнего собственника.

Онлайн сервисам можно доверять на все 100 процентов, но чтобы полностью развеять сомнения, лучше сразу же отправиться в ближайшее отделение ГИБДД, где штатный сотрудник проверит машину по всем своим базам данных, эта услуга предоставляется бесплатно. Не забывайте также об онлайн реестре залогового имущества Федеральной Нотариальной Палаты, где машину также можно проверить по ВИН-коду.

Загрузка...

Поделиться в социальных сетях

Как правильно проверить подлинность ПТС

При покупке подержанного автомобиля необходимо проверить множество деталей.

Оценка состояния транспортного средства включает целостность кузова и деталей или компонентов, состояние колёс и других агрегатов. Но не многие автолюбители знают, что одно из первых, на что необходимо обратить внимание, является специальная документация – ПТС или паспорт технического состояния.


Что такое подлинный ПТС

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

ПТС предоставляет подробную информацию о всех «похождениях» транспортного средства перед тем, как он попал к вам. Оригинальный ПТС предоставляет такие данные:

  1. Количество предыдущих владельцев автомобиля. Если транспортное средство за свою жизнь меняло много хозяев, и частота продажи велика, то вам стоит подумать, настолько ли будет оправдана покупка такой машины.
    Также обратите внимание на то, сколько времени прошло с момента последней продажи авто – если прошло немного времени, то, скорее всего, автомобиль потребует значительных капиталовложений, которые увеличат конечную стоимость и без того дорогостоящей покупки.
  2. Обратите внимание на графу «Основание», что указывает документы, на основе которых осуществлялась передача транспортного средства до вас. Внимание должна привлечь фраза «договор залога», свидетельствующая о том, что автомобиль находился в кредите, и, по всей видимости, с его погашением возникли проблемы. От такой сделки лучше отказаться.
  3. Также обратите внимание на отметки, свидетельствующие о том, что автомобиль был пригнан из-за границы. При пересечении владелец транспортного средства обязан уплатить пошлины. В противном случае авто могут изъять.
  4. Первое свидетельство того, что перед вами оригинальный ПТС – VIN-код автомобиля, прописанный в документе. Обязательно сравните его с тем, что набит непосредственно на кузове машины.
    Обычно он расположен под капотом или на стойке двери со стороны водителя.
  5. Также внимательно проверьте ПТС и определите страну-производителя. В большинстве случаев автомобили из развивающихся или бедных стран были повреждены и имеют видимые следы сварки по кузову.
Важно! Обязательно удостоверьтесь в том, что у вас в руках находится оригинал ПТС.

Если продавец передал вам копию документа, расспросите его о причинах.

Законодательство чётко прописывает причины выдачи дубликата ПТС:

  • Если собственник автомобиля потерял или повредил оригинал ПТС.
  • Если хозяин транспортного средства сменил свои идентификационные данные, а именно Ф. И.О., место регистрации и т. п.
  • Дубликат выдаётся тогда, когда в оригинале заканчивается отведённое для записей место.

Незаконопослушные продавцы в большинстве случаев предоставляют подделки ПТС, чтобы быстро и недорого продать угнанный автомобиль невнимательному покупателю. Дубликат ПТС является явным свидетельством того, что с машиной что-то не так, включая её тёмное прошлое. При последующей возможной перепродаже дубликат ПТС может стать причиной отказа потенциального клиента от покупки.

Кто и зачем продаёт копии и подделки

Копии и поддельные документы на автомобиль, очевидно, делаются для продажи/перегона угнанных или «чёрных» автомобилей. Любое действие с поддельными документами влечёт за собой уголовную ответственность. Если вы заподозрили или определили, что у вас в руках находится подделка, обязательно откажитесь от такой сделки, и по возможности сообщите о нарушении в правоохранительные органы.

Внешняя проверка подлинности ПТС

Внешняя проверка ПТС на подлинность должна проводиться максимально тщательно. Не забывайте, что подделать ПТС сегодня для злоумышленников не составляет никакого труда, а вы можете стать жертвой мошенников и остаться ни с чем. Документ печатается на синем бланке размером 200х310 мм. Плотность картона похожа на плотность бумаги, на которой печатается приложение к диплому ВУЗа или свидетельство о браке.

Каждая страница ПТС содержит следующие обозначения:

  • Специальная голограмма (изображение нового формата имеет круглую форму, внутри изображён автомобиль, на старых бланках голограмма нанесена в виде пунктирной линии).
  • RUS – водяной знак.
  • Защитная полоса.
  • Теснённый рисунок.
  • Специальный мелкий текст.

Дубликат ПТС практически ничем не отличается от оригинала. Единственное отличие – круглая печать на главной странице документа. Получить дубликат паспорта можно в любом отделении ГИБДД вместо потерянного или повреждённого оригинала.

Чтобы правильно проверить ПТС на достоверность и оригинальность, возьмите документ в руки. Для проверки подготовьте увеличительное стекло и фонарик. Оригинальный ПТС имеет такие характеристики:

  • Голограмма нанесена чётко, без прерывистых линий, имеет чёткие границы.
  • Непосредственно над голограммой в оригинале документа нанесена невидимая надпись ПТС. Чтобы проверить это, просветите документ фонариком и осмотрите его под небольшим углом.
  • Водяные знаки RUS проявляются при просвечивании фонариком.
  • Специальный мелкий текст – «паспорттранспортногосредства» – чётко видно под увеличительным стеклом.
  • Теснённый рисунок при изменении угла просмотра становится серым вместо зелёного.

Если у вас есть возможность проверить документ под ультрафиолетом, обязательно сделайте это – весь бланк покрывают специальные метки, похожие на голограммы на купюрах. От середины бланка нанесена невидимая теснённая линия, которая длится до микротекста «паспорттранспортногосредства».

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

Дальше обязательно проверьте достоверность всех внесённых в ПТС данных:

  • Серия и номер документа.
  • VIN-код автомобиля.
  • Марка и модель транспортного средства.
  • Категория автомобиля.
  • Дата выпуска.
  • Тип мотора.
  • Номер и цвет кузова.
  • Снаряжённая и пустая масса.
  • Максимальная грузоподъёмность.
  • Мощность и объём двигателя.
  • Место производства.
  • При импорте авто – страна-производитель, класс выбросов, данные об оформлении декларации при пересечении границы.
  • Дата выдачи, наименование организации, выдавшей ПТС.
  • Данные владельца.

Первые признаки того, что у вас в руках поддельный документ:

  • В номере документа прописан код региона, где он выдавался. Проверьте соответствие этих данных – номер указан сверху, первые цифры – код региона. Данные о месте выдачи указаны внизу на той же странице бланка.
  • VIN в ПТС и непосредственно на автомобиле не совпадают.

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

Другие места для поиска идентификационных номеров транспортных средств включают багажник, опорный кронштейн радиатора и такие детали, как двигатель и рама. На старых автомобилях проверяйте переднюю часть рамы автомобиля, когда дверь открыта. Если вы можете открыть капот на автомобиле, оснащённом бензиновым двигателем, посмотрите номер, указанный на переднем блоке двигателя. Для мотоциклов проверьте основание руля, раму рядом с двигателем или сам двигатель. Чтобы найти VIN на полуприцепе, посмотрите на переднюю левую стойку, со стороны водителя транспортного средства.

Возможно, вы не стоите перед автомобилем, но имеете доступ к его страховым документам. VIN-коды появляются на документах, таких как страховые карты, страховые полисы, документы о регистрации транспортных средств. Идентификационный номер часто указывается в руководстве по эксплуатации конкретного автомобиля. Он указан в счёте-фактуре поставщика и в чеке продажи у дилера и должен быть в счёте или в продаже и квитанции от частного продавца.

  • Дата производства ПТС меньше, чем дата составления данного паспорта транспортного средства.

Проверка подлинности ПТС по базе ГИБДД

Самое верное решение, чтобы отличить подделку проверить паспорт на подлинность – через базы данных ГИБДД. Для этого обратитесь в любое отделение, где вам предоставят развёрнутую информацию. Помимо достоверности документа, сотрудник ГИБДД предоставит вам следующую информацию:

  • Наличие просроченных или неуплаченных штрафов в ГИБДД.
  • Попадало ли авто в дорожно-транспортное происшествие.
  • Числится ли автомобиль в угоне.
  • Можно ли продавать автомобиль.

В некоторых случаях сотрудники ГИБДД могут предоставить всю информацию в телефонном режиме. В противном случае обращайтесь непосредственно в отделении по номеру транспортного средства.

Проверка подлинности ПТС онлайн

Проверить подлинность ПТС также можно не выходя из дома. Достаточно посетить сайт ГИБДД.

Важно! Иногда на сайте ГИБДД может содержаться устаревшая информация, поэтому точно определить оригинальность ПТС можно только в отделении при личном визите.

Перейдите в соответствующий раздел, и введите требуемую информацию об автомобиле (например, VIN или номер кузова/шасси).

На сайте через интернет можно получить такую информацию:

  • Актуальные данные про машину.
  • Наличие неуплаченных штрафов и другие нарушения.
  • Можно ли осуществлять любые регистрационные действия с данным автомобилем.
  • Есть ли заявления об угоне данного транспортного средства.

Совершая покупку транспортного средства необходимо быть крайне внимательным. Мошенники подделывают не только регистрационные документы на машину, но и ПТС. Следуйте нашим инструкциям, и вы не попадёте в лапы мошенников. Если вы сталкивались с неоригинальными ПТС, расскажите об этом в комментариях под статьёй.

на подлинность, на ограничение регистрационных действий, на арест и залог, на трафы и историю собственников

Собираясь покупать мотоцикл или другое ТС с рук велик риск нарваться на мошенников. Поэтому к проверке документов отнеситесь с максимальным вниманием.

Проверка VIN, номера рамы и двигателя

Прежде чем начинать осмотр ТС проверьте все номера на ПТС и на приобретаемом транспорте. В тех местах где номер на раме или кузове осмотрите на предмет переделок. Злоумышленники часто перебивают номера на двигателе, на раме или кузове — вваривают целые куски металла с номером другого ТС. Так же стоит проверить:

  • Марку и модель
  • Цвет
  • Изготовителя ТС
  • Страну вывоза
  • Информацию о растаможке
  • Сравните информацию о текущем владельце в ПТС и СТС.

Если все данные верны — проверим бланк ПТС на оригинал.

Проверка бланка ПТС

Паспорт транспортного средства имеет несколько степеней защиты.

Узоры по всему бланку — должны быть чёткие и ровные, аккуратно и симметрично прорисованы.

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

На последней странице ПТС есть узор, объемный на ощупь. В зависимости от угла обзора его цвет меняется от серого до ярко-зелёного.

Еще одна степень защиты — водный знак RUS*, который видно на просвет по всей площади листа ПТС.

Как проверить ПТС онлайн

После того как вы удостоверились в подлинности бланка ПТС и данные на самом транспортном средстве, самое время проверить данные с помощью сайта ГИБДД онлайн.

 

Переходим по ссылке на сайт ГИБДД: http://www.gibdd.ru/check/auto/#

В верхней части вводим VIN номер в поле, и запрашиваем интересующие проверки.

Что можно пробить через онлайн базу ГИБДД:

  • историю собственников
  • проверить через вин находится ли ТС в залоге
  • проверить автомобиль перед покупкой на юридическую чистоту
  • проверить автомобиль у судебных приставов
  • проверить автомобиль на ограничение регистрационных действий
  • проверить подлинность птс

Вы можете проверить информацию о ТС такую как модель, год выпуска и тд. Но самое важное — количество владельцев — оно должно совпадать с тем что написано в ПТС.

Так же можно узнать о зарегистрированных ДТП с участием этого автомобиля или мотоцикла:

Проверка на запрет регистрационных действий по тем или иным причинам:

Так же можно узнать не находится ли ТС в розыске или угоне:

Таким образом вы сможете проверить перед покупкой всю информацию о транспорте в онлайн режиме прямо со смартфона или компьютера.

 

Как проверить юридическую чистоту автомобиля?

  1. АТЦ Москва
  2. Статьи
  3. Как проверить юридическую чистоту автомобиля?

В АТЦ «Москва» все автомобили проходят проверку на юридическую чистоту. Наши сертифицированные эксперты-криминалисты проверяют не только данные автомобиля, но и всех его собственников, что позволяет на 100% гарантировать юридическую чистоту каждого автомобиля.

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

Мы расскажем, как проверить документы перед покупкой транспортного средства, и для чего необходима такая проверка.

Какой бы автомобиль вы не решили купить – подержанный или новый, необходимо очень внимательно проверять всю документацию на машину.


Проверка авто на юридическую чистоту включает в себя несколько обязательных пунктов:

1. Проверка документов на автомобиль

2. Проверка по базам ГИБДД на нахождение в розыске

3. Находится ли транспортное средство в залоге или аресте

4. Таможенная проверка (если машина ввезена из-за рубежа)

Проверка документов на автомобиль должна выполняться как можно тщательнее. В обязательном порядке у продавца транспортного средства должны быть в наличии:

- Паспорт транспортного средства (ПТС)

- Свидетельство о регистрации ТС (техпаспорт)

- Нотариально заверенная доверенность на имя продавца (если продавец не является владельцем авто)


ПТС – самый главный документ каждого автомобиля. В паспорте прописана основная информация о машине: модель, номера двигателя и кузова, объем двигателя, VIN-код, цвет, собственники и т.д.

Первым делом при покупке подержанного транспортного средства проверьте совпадение VIN-кода в ПТС и на автомобиле. VIN-код – это 17-значный номер, который находится на авто под капотом и на металлической раме автомобиля. Номера могут размещаться и на других частях машины, все зависит от её модели. Также сверьте номер двигателя, прописанный в ПТС и выбитый на шильдике силового агрегата.

Обязательно обратите внимание на графы, в которые вписаны имена собственников машины. В том случае, если не осталось свободных граф для занесения данных о новом владельце, то просите продавца автомобиля поменять ПТС на новый в МРЭО ГИБДД. Без предыдущего собственника машина, Вы не сможете зарегистрировать купленный автомобиль.

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

- при утере

- порче оригинала

- когда автомобиль находится в залоге


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

Установить подлинность ПТС возможно и по содержащимся на нем элементам. Обратите внимание на орнамент паспорта. Это специфический узор, который четко виден при его детальном рассмотрении. Чёткой и легко читаемой должна быть и голограмма. В углу на обратной стороне паспорта находится своеобразный объёмный узор в виде розочки. Рисунок хорошо определяется наощупь и под углом меняет цвет от зеленого до серого. И последнее, что нужно проверить – наличие объемного водяного знака «RUS».

Также в ПТС заносятся данные по ситуации с таможенными органами. Если машина была ввезена из-за границы, то в специальной графе «Таможенные ограничения» должна находиться информация об оплате пошлин, а также, не наложены ли на владельца машины ограничения по распоряжению автомобилем. Записи про «отчуждению не подлежит» или «временный учет до…» означают то, что автомобиль либо не растоможен, либо ввезен временно. При покупке такой машины Вам придется потратиться дополнительно, заплатив таможенный сбор, или столкнуться еще с рядом проблем, которые Вам так или иначе придется решать.

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

Наиболее верный способ узнать подлинность ПТС – проверка его по базам ГИБДД. В Госавтоинспекции выдают информацию о штрафах, о нахождении авто в угоне, о ДТП с участием машины, актуальности сверки номеров двигателя, кузова, шасси и прочего, запрет на изменение регистрационных данных.

Сегодня проверить ПТС на подлинность возможно и не приезжая в ГИБДД. Сделать это возможно онлайн с помощью официальной базы ГИБДД. Для этого введите туда регистрационные данные авто (номер кузова, шасси или VIN-номер). Сервис выдаст Вам всю имеющуюся об автомобиле информацию.


Несомненно, при покупке подержанного авто возникают вопросы: не краденый ли он, не числится ли в угоне? И это не удивительно, ведь сегодня очень легко можно купить краденое авто и даже не догадываться об этом. В итоге Вы рискуете остаться без денег, без автомобиля, и приобрести неприятности с законом.

Самым верным и надежным вариантом проверки автомобиля на угон будет обращение в ГИБДД. Другие существующие варианты проверки, например обращение в специальные коммерческие конторы, не всегда способны выявить мошеннические схемы с авто. Причина неудач может крыться в перебитом номере автомобиля. Поэтому лучше обращаться в госучреждения с официальными базами данных.

При этом следует помнить, что базы ГИБДД выдают данные только угнанных на территории России авто. Гарантий, что автомобиль не был угнан за границей, не могут дать даже в Госавтоинспекции, только если машина не проходит по линии Интерпола. Криминальным будет считаться и авто, у которого поменяли двигатель и набили на него старый номер. И такие ситуации часто встречаются.

Не отчаивайтесь, если в Госавтоинспекции Вам заявили, что автомобиль числится в угоне. Существует вероятность, что ее спутали с машиной «двойником». В ГИБДД проверяют авто только по последним цифрам VIN-кода, а они могут совпадать с номером угнанной машины.


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

Во-первых, если автомобиль незначительно старый, то у владельца должно быть два комплекта «родных» ключей. Один ключ обычно отдают те владельцы авто, которые проводили замену замков в машине. Но, по какой причине? Вот здесь стоит задуматься. Ответить Вам могут что угодно, а расплачиваться за ошибку придется только Вам.

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

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

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


Старайтесь использовать все возможные варианты проверки и совершайте только официальное переоформление документов. Только таким способом Вы избежите неприятных сюрпризов с приобретенным автомобилем.

И обязательно выясните, не находится ли предлагаемый Вам автомобиль в залоге. Ситуация на сегодня такова, что далеко не все могут похвастаться отсутствием кредитов. Тем, кто хочет купить авто посолиднее, приходится брать заём в банке под залог транспортного средства. В итоге многие водители ездят не на своих автомобилях и часто пытаются их продать вместе с кредитом. Выяснить, находится ли авто в залоге по какой-то официальной базе не представляется возможным, так как в России она просто не существует. Единственной гарантией для покупателя остается оригинал ПТС. Дело в том, что банки обычно не отдают ПТС на руки, пока кредит не будет полностью погашен.

Однако так поступают не все кредитные организации, поэтому вполне вероятно, что ПТС покажут оригинальный. Но, тут существует еще одна подстраховка для покупателя. В МРЭО на автомобиль накладываются регистрационные ограничения, поэтому снять его с учёта при продаже не получится. По правилам при нахождении машины в залоге должен оформляться договор поручения. Фиксируется он в ПТС в пункте «Особые отметки».

Как же все-таки убедиться, что кредит продавец закрыл? Попросите его предъявить документ из банка, в котором будет прописано о закрытии кредитных обязательств. Также Вы можете попросить показать Вам договор купли-продажи из автосалона с кассовыми чеками. При отсутствии этих документов покупать автомобиль точно не следует.

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


Кроме того, обратите внимание на стоимость автомобиля, если она занижена, то это может свидетельствовать о желании владельца как можно быстрее продать авто. Перед покупкой тщательно изучите цены на модель приобретаемой машины.

Также требуйте у продавца договор купли-продажи. Если он не может предъявить этот документ, то, скорее всего, автомобиль находится в залоге.

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

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

И последнее, что Вы можете сделать - проверить машину по Vin-номеру. Сделать это можно онлайн на сайте http://www.gibdd.ru/check/auto. Если поисковая система найдет такой автомобиль в базе, то на него наложены обременения.

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


Каждый автомобиль, импортированный на территорию РФ, обязан иметь соответствующую запись в ПТС о прохождении таможенного контроля с печатью и подписью сотрудника таможни. Если в ПТС есть записи такие как: «Таможенные ограничения отсутствуют», «Платежи оплачены, отчуждение разрешено», «Ввоз разрешён при уплате пошлины», - в чистоте автомобиля можно быть уверенным.

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

После покупки автомобиля возникает необходимость его постановки учет. АТЦ «Москва» предоставляет своим клиентам возможность постановки автомобиля на учет. После приобретения автомобиля в любом из наших автосалонов вы можете сразу же оформить заявку на регистрацию автомобиля в ГИБДД. Вам не нужно никуда ехать, стоять в очередях и делать кучу копий документов. Весь процесс оформления возьмут на себя сотрудники специализированной организации прямо в здании торгового центра.


Выбрав автомобиль, вы можете выехать с территории торгового центра на автомобиле уже зарегистрированном в ГИБДД. 

Как проверить ПТС на подлинность перед покупкой автомобиля

Купить подержанный автомобиль – это выгодно. Но и здесь есть свои подводные камни и о них стоит знать. Актуальный пробег, износ машины, и, конечно, проблема с документами.  В нашей статье мы расскажем как проверить один из важнейших документов на авто перед его приобретением –  ПТС.

Паспорт на машину (ПТС) –  содержит самую важную информацию.

Важно: первое, на что необходимо обратить внимание  совпадает ли ВИН номер на машине  и в паспорте! Идентификатор представляет собой 17-значное число, его можно обнаружить в определенных местах машины: на раме, непосредственно под капотом. В разных моделях число может наноситься и в других местах.

И, конечно, ПТС содержит сведение о номере двигателя –  на авто он отображен на силовом агрегате.

Кроме основных показателей, проверяем и такие:

  • Цвет машины.
  • Госномера.
  • Марка.
  • Масса транспортного средства.
  • Объем двигателя.
  • Модель.
  • Номер шасси.
  • Дата производства.

Подлинный ли ПТС?

Чтобы понять, подлинник перед вами или качественная подделка, обращаем внимание на такие детали:

 

  • Голограмма на ПТС –  четкая, легко можно прочесть указанные данные. Этот элемент очень трудно подделать.
  • Орнамент документа –  это специальный узор, Если его детально рассмотреть - он не должен потерять визуальной четкости.
  • Рисунок (в объеме) –  находится на оборотной стороне ПТС в углу –  розочка. Прощупайте его, он должен быть четким и легко ощутимым. Рисунок должен поменять свой оттенок в зависимости от угла падения света: от  ярко-зеленого до бледно-серого.
  • Водяной знак – при просвечивании документа, вы должны обнаружить объемную надпись «RUS».

Видео - Как правильно читать Паспорт Транспортного Средства

Документы на иномарку

Если приобретаете «иностранца» то учтите, что ПТС может выдать только Таможенная служба. В такой ситуации вы обязаны обратить внимание на страну, в которой изготовлен автомобиль. Если в паспорте указаны страны Беларусь или Литва –  вас должно это насторожить, ведь именно в этих странах чаще всего собирают транспортное средство из нескольких непригодных для езды авто, или просто оно было тщательно восстановлено после серьезной аварии!

Важно: в паспорте, который выдает таможня, могут указываться определенные ограничения. Типы санкций: отчуждение или запрет на продажу машины. ПТС заверяется работником таможни подписью ответственного лица и мокрая печать.

Авто в кредите

Понять что перед вами кредитное имущество можно по таким признакам:

  • Дубликат паспорта –  чаще всего оригинал остается у банка, а владелец просто заявляет, что его потерял и изготовляет дубликат.
  • Дата выпуска машины –  как правило, машины новые.
  • Пробег – невелик.

Дубликат ПТС –  в чем опасность?

К сожалению, именно повторно выданный документ используют в своих схемах аферисты. То есть при продаже предлагают вам не оригинал, а поддельный дубликат. Хотя вас и будут уверять, что ПТС просто потерян или хозяева меняли свои личные данные.

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

Проверяем ПТС через ГИБДД

Свой документ можно пробить по базам ГИБДД. Необходимо обратиться к сотруднику органа, и вам обязаны выдать полную информацию по паспорту автомобиля. Так вы сможете узнать не только о подлинности паспорта:

 

  • Проверить наличие неоплаченных штрафов.
  • Не числится ли машина в угоне.
  • Была ли она в ДТП.
  • Если запрет на регистрационные действия, в том числе и продажу.
  • Есть возможность сверить актуальные данные ПТС с нанесенными на авто.

Некоторые отделения ГИБДД готовы предоставить полную информацию и в телефонном режиме. Если отказывают –  пишите заявление о предоставлении информации по ПТС.

Где проверить ПТС онлайн

Все о ПТС вы сможете уточнить на сайте ГИБДД http://www.gibdd.ru/check/auto/. Вводим на страничке информацию о регистрационных данных на машину (достаточно номера кузова, ВИН или шасси). Сайт выдает такие показатели:

  • Вся информация об актуальных данных на автомобиль.

Есть ли неуплаченные штрафы, каковы их размеры.

  • Наложен ли запрет на осуществление правовых действий – санкции любого органа.
  • Числится ли машина в угоне.

Можно обратиться и к другим авторитетным ресурсам:

Существуют и другие сервисы, где можно проверить паспорт на авто.

Важно: учтите, что недостатком  таких проверок (сайтов) может быть информация, которая уже устарела. Так что стоит перестраховаться и обратится в ГБДД с заявлением лично.

Будьте крайне внимательны, приобретая не новый автомобиль –  особое внимание уделяйте проверки полного пакета документов, правильно составляйте договор купли-продажи, сверяйте личные данные продавца с гражданским паспортом.

Как проверить ПТС на подлинность по базе ГИБДД онлайн

Общая информация

Рассмотрим, как можно проверить ПТС.

  1. Путем личного обращения в ГИБДД. Сотрудники Госавтоинспекции предоставят максимум информации по вашему запросу. Для этого вам необходимо будет предъявить сотруднику ГИБДД документы на автомобиль.
  2. Позвонив по телефону в Госавтоинспекцию и назвав основные данные из ПТС.
  3. Воспользовавшись онлайн-сервисом ГИБДД.
  4. Воспользовавшись сторонними ресурсами, предлагающими узнать больше информации о вашем ТС, например, о том, не пребывает ли выбранный автомобиль в угоне.

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

Сервисы онлайн проверки, которые не относятся к государственным, в лучшем случае будут черпать информацию из государственных сайтов, в худшем – будут давать искаженные сведения. Так, не лучше ли самостоятельно воспользоваться надежным источником? Тем более, так вы будете уверены, что получили самые свежие данные.

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

По государственному номеру доступна лишь проверка штрафов, которые не уплатил водитель. Информацию можно найти на сайте ГИБДД в соответствующем разделе. Кроме госномера, необходимо в специальное поле вписать также номер свидетельства о регистрации.

✔ Проверка по VIN.

С помощью ВИН-кода можно узнать множество полезной информации. Например, с помощью VIN-кода на сайте Федеральной нотариальной палаты можно узнать, находится ли автомобиль в залоге. Также можно проверить, не числится ли авто в международном розыске. Для поиска этой информации существует достаточно много различных сервисов.

Во-первых, уже несколько лет существует возможность проверки ряда информации по автомобилям и их владельцам на официальном сайте ГИБДД по единым базам данных.

  1. Проверка по базе штрафов ГИБДД
  2. Проверка транспортного средства по VIN номеру
  3. Проверка подлинности водительского удостоверения по номеру

В настоящий момент вы легко можете проверить задолженности по штрафам ГИБДД, имея на руках государственный номер авто и данные СТС, причем есть несколько способов:

  • Во-первых, можно позвонить по телефону в ГИБДД, продиктовать личные данные и номер СТС и после проверки по базе данных штрафов вам сообщат, есть ли у вас задолженность;
  • Есть возможность проверить штрафы на сайте ГИБДД, где по государственному номерному знаку автомобиля и номеру СТС можно выяснить информацию о штрафах по данному автомобилю;

Кстати, на текущий момент многие крупные банки в России дают возможность проверить штрафы ГИБДД онлайн в личном кабинете и тут же их оплатить. Помимо этого на сайте государственных услуг в личном кабинете также можно увидеть неоплаченные штрафы за нарушение ПДД или за неправильную парковку.

Если говорить о проверке авто по VIN-коду, то официальный сайт ГИБДД позволяет:

  • Проверить историю регистраций авто в ГИБДД — получить основные сведения о ТС и периодах его регистрации в ГАИ за различными собственниками.
  • Проверить на участие автомобиля в ДТП — вы можете получить сведения о дорожно-транспортных происшествиях с участием автомобиля с указанным VIN-номером, произошедших с начала 2015 года (но только те ДТП, которые оформлялись при участии сотрудников полиции и были внесены в федеральную базу АИУС ГИБДД)
  • Проверить нахождения машины в розыске — вы можете получить сведения о федеральном розыске автомобиля правоохранительными органами.
  • Проверить наличие ограничений на регистрационные действия с ТС в ГАИ — с помощью данной проверки вы можете получить сведения о наличии тех или иных ограничений на проверяемое транспортное средство.

Еще одним онлайн-сервисом на официальном сайте ГИБДД является «проверка подлинности водительского удостоверения по номеру», чтобы воспользоваться этой бесплатной онлайн-услугой вам необходимы данные и номер ВУ.

Из базы ГИБДД при личном обращении в подразделения Госавтоинспекции можно получить не только сведения о штрафах и долгах по ним, но и такие данные как:

  • Дата регистрации автомобиля, юридическая история автомобиля и информация обо всех его прежних владельцах;
  • Все идентификационные сведения автомобиля для сверки данных, внесенных в ПТС, с данными, имеющимися в ГИБДД, а именно:
    — Данные о марке автомобиля;
    — Производителе автомобиля;
    — Массе автомобиля;
    — Номере модели автомобиля;
    — Цвете автомобиля и коде окраски;
    — VIN-коде;
    — Дате выпуска автомобиля;
    — Номере шасси;
    — Номере двигателя;
    — Мощности двигателя;
    — Государственном номере.
  • Информацию о наличии запрета на действия по регистрации собственности в отношении  автомобиля;
  • Данные о наличии наложенного ареста на автомобиль;
  • Данных обо всех авариях, в которых ваш автомобиль принимал участие, кроме факта аварии, можно выяснить, где произошла авария, в какое время и кто был ее участником;
  • Данные о нахождении автомобиля или его частей (двигателя, кузова) в розыске.

В отдельных городах России, таких как Москва и Санкт-Петербург, например, можно получить справочную информацию по числящимся за автолюбителем задолженностям по оплате штрафов по телефону. Для этого достаточно продиктовать госномер транспортного средства и водительского удостоверения.

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

На текущий момент такой возможности нет, нельзя проверить ПТС автомобиля через интернет по базе ГИБДД ни на официальном сайте Госавтоинспекции, ни на сторонних онлайн-сервисах.

Будьте бдительны и не доверяйте сомнительным сайтам, обещающим проверить ПТС по номеру онлайн по базе ГИБДД, личную персональную информацию, и тем более не вводите свои платежные данные банковских карт.

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

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

Один из самых распространенных вариантов мошенничества – продажа авто с поддельным ПТС. За счет этого можно легко скрыть предыдущую, как правило криминальную, историю машины.

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

Поэтому перед тем, как приобретать поддержанное транспортное средство, необходимо проверить его ПТС.

Большинство случаев продажи транспорта с подделанным ПТС выявляется именно при продаже поддержанных иностранных автомобилей. Причем опасаться стоит не только недорогих автомобилей, но и авто премиум-класса (как правило, такие транспортные средства не прошли таможню).

Достаточно часто встречаются случаи, когда на территорию страны привозится так называемый «конструктор», который собирается под данные, указанные в ПТС. В таком случае все, что остается мошенникам, перебить старый номер ПТС в особых отметках.

Существует несколько косвенных признаков, при помощи которых можно определить «чистоту» приобретаемого транспортного средства:

  1. Продавец передает два комплекта оригинальных ключей от авто.
  2. В ПТС нечастая смена владельцев.

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

Также лучше всего не приобретать автомобиль, в паспорте которого указаны в качестве стран-производителей Беларусь или Литва. Высока вероятность, что транспорт был восстановлен после дорожно-транспортного происшествия или собран из нескольких частей.

Проверка авто по номеру ПТС на сайте ГИБДД

Сервис Госавтоинспекции разработан недавно (в 2013 году) и является достаточно простым в использовании.

  1. Зайдите на официальный сайт ГИБДД.
  2. Откройте раздел «Сервисы».
  3. В открывшемся меню выберите «Проверка автомобиля».
  4. Введите номер VIN, или номер кузова, или номер шасси.

К сожалению, по серийному номеру ПТС поиск возможен только для жителей Москвы. Для этого следует:

  1. Зайти на сайт мэра города.
  2. Зайти в раздел «Транспорт».
  3. Выбрать «Проверка ПТС».
  4. Ввести серию и номер ПТС.

Информация черпается из баз ГИБДД, поэтому сведениям можно доверять.

С помощью ВИН-кода, номеров кузова или шасси можно узнать следующую информацию:

  • Об основных характеристиках авто.
  • Об ограничениях, наложенных на ТС.
  • О датах перерегистраций машины на новых владельцев.
  • О пребывании авто в розыске.
  • Об авариях, в которых участвовала машина.

Проверка по серийному номеру ПТС введена относительно недавно и пока что показывает москвичам такие данные:

  • Количество владельцев, даты перерегистраций.
  • Основные характеристика авто – марка, тип, год выпуска, категория ТС, цвет, параметры двигателя, грузоподъемность.
  • цвет автомобиля;
  • модель и марка;
  • госномер;
  • объём двигателя — обычно указывается на шильдике на задней стороне авто;
  • дата выпуска — также может указываться на шильдике под капотом;
  • масса автомобиля — можно проверить в ближайшем автосервисе;
  • номер шасси.
  • неоплаченные штрафы;
  • является ли авто в угоне;
  • есть ли запрет на изменение регистрационных данных;
  • информацию о данных автомобиля.

http://vinformer.su/ru/ident/title/ — сервис для проверки автомобилей, ввезённых из другой страны после 1996 года.

http://shtrafy-gibdd.ru/ — ещё один сервис, который выдаст всю информацию о неоплаченных штрафах.

Также в сети существует множество других сервисов для проверки авто, но принцип работы практически не отличается. Минусом такой проверки является то, что информация может быть неактуальной (за исключением официального портала ГИБДД). Таким образом, наиболее точную и актуальную информацию Вам смогут предоставить лично в ГИБДД.

Также рекомендуем вам ознакомиться с другими полезными и бесплатными онлайн сервисами для автомобилистов в этой статье —


« Предыдущая запись Следующая запись »

на дубликат, по номеру, по базе ГИБДД

Сегодня многие водители приобретают ввезенные в страну подержанные авто. Причина такой популярности в адекватной стоимости автомобилей этой категории. Но существуют и подводные камни, которые необходимо обязательно учесть при планировании покупки. К ним относится наличие скрытых повреждений, ведь большой пробег становится причиной износа деталей, а также возможные проблемы с документами. Все чаще задают вопрос «Как проверить ПТС перед покупкой?»

Чтобы избежать неприятностей, внимательно проверяйте ПТС. Это можно сделать несколькими способами.

Способы проверки ПТС на подлинность

ПТС – самый главный документ, в котором перечислены технические характеристики транспортного средства. Он необходим для оформления залога и кредита, а также при регистрации машины в ГИБДД. Существует три способа проверки данных ПТС на подлинность перед покупкой.

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

  1. Консультация с сотрудником ГИБДД по телефону, либо при личном визите.
  2. Проверка ПТС по базе ГИБДД онлайн, здесь вы найдете сведения о машине. Для проведения поиска понадобится номерной знак.
  3. Обращение к сайтам-сервисам, на которых можно провести поиск сведений по базам данных.

Проще всего узнать о задолженности по штрафам путем посещения отделения ГИБДД. Предъявите инспектору водительское удостоверение, он изучит информацию и выдаст вам полную выписку. В ней будут отражены сведения об оплаченных и неоплаченных штрафах.

Многие водители закономерно считают, что такой способ не очень удобен. Во-первых, необходимо потратить время на дорогу до ГИБДД. Во-вторых, не все водители располагают свободным временем. Но только так вы можете получить точные и актуальные данные от представителей инспекции. Воспользовавшись таким способом получения информации, вы узнаете последние данные, которые еще не дошли до интернет-сервисов.

Проверка ПТС по базе ГИБДД

Используя сайт ГИБДД водители не только получают сведения о штрафах, но и информацию об автомобиле. Это дата его регистрации, информация о совершении сделок в отношении машины, данные о владельцах. Кроме того, вы можете узнать следующие идентификационные данные авто:

  • марка и модель транспортного средства;
  • номер шасси, двигателя и Vin-номер;
  • мощность двигателя, масса машины, ее цвет;
  • производитель транспортного средства, дата производства машины;
  • государственный номер.

Эти данные помогут установить подлинность документа, их используют при проведении сверки. Кроме того, вы можете узнать о том, не наложен ли арест на автомобиль, действует ли запрет на регистрацию машины, не находится ли транспортное средство, либо его агрегаты в розыске. Вы получите в свое распоряжение данные об авариях, их даты и местоположение. Также будет информация об участниках ДТП.

На сайте ГИБДД возможна проверка авто по номеру кузова, по номеру машины, по VIN, серии и номеру ПТС.

Проверка штрафов ГИБДД по ПТС

В некоторых городах, штрафы ГИБДД можно проверить по ПТС автомобиля и номеру машины, владельцы транспортных средств достаточно позвонить по телефону ГИБДД. Если вы желаете воспользоваться подобной услугой, назовите имеющиеся у вас реквизиты документов на автомобиль.

Вы можете узнать информацию о штрафах, отправив СМС-сообщение. Такая услуга предоставляется рядом инспекций.

Дубликат ПТС и его подлинность

Внимательно осмотрите ПТС. Оригинальный документ отличается наличием орнамента, этот узор должен быть четким даже при детальном рассмотрении. На подлинном документе обязательно стоит голограмма, она должна легко читаться, быть четкой. Мошенникам очень трудно подделать этот элемент.

Посмотрите на обратную сторону ПТС. Здесь находится объемный рисунок, он имеет вид розочки. Если смотреть на нее под разным углом, то она меняет цвет. Вы определите такой рисунок на ощупь, а при просвечивании на документе виден водяной знак. На ПТС написано «RUS».

Обратите внимание на заполнение документа, данные в ПТС не вносятся вручную. Вся информация в паспорте напечатана. Зная эти особенности, вы легко отличите подделку от оригинального документа.

Как проверить зарубежное авто и ПТС на подлинность

В России много автомобилей иностранного производства, выдачей ПТС в этом случае занимается только таможенная служба. Паспорт обязательно заверяется подписью таможенника, на документе должна стоять печать. В таком ПТС могут быть указаны ограничения, они могут касаться продажи автомобиля.

Нужно сказать, что ПТС подделывают чаще всего при реализации подержанных иномарок. Они поступают либо с перебитыми номерами, либо «конструктор» привозят в страну, ориентируясь на ПТС, а потом собирают авто на месте. Как действовать в таком случае? Проще всего посмотреть на предыдущий документ, изучить на дубликате «Особые отметки». Автомобиль можно считать «чистым», если при продаже вам вручили два комплекта ключей. Кроме того, на это же указывает нечастая смена владельцев транспортного средства.

При проверке документа вас должны насторожить следующие моменты:

  • первичный ПТС был выдан в одном регионе, а дубликат – в совершенно другой местности;
  • дубликат ПТС оформлен через малый промежуток времени.
Тщательно проверяйте транспортные средства, ввезенные с территории Литвы и Беларуси. Очень многие машины собираются из нескольких частей после ДТП.

Проверить историю можно в базе украденных автомобилей, либо на VIN-INFO. Узнать о машинах, ввезенных после 1996 года, можно на ресурсе VINformer. Машины из Северной Америки проверяют на AutoChek, также можно пользоваться ресурсом Carfax.

Кредитные автомобили

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

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

Видео: как проверить автомобиль по ПТС по номеру кузова, серии и VIN на сайте ГИБДД.

Настроить опцию аутентификации TCP (TCP-AO) | Руководство пользователя транспортных и Интернет-протоколов

РЕЗЮМЕ В этом примере показано, как создать TCP-AO. связка ключей для аутентификации сеанса BGP или LDP.

В этом примере используется следующее оборудование и программное обеспечение. компонентов:

В этом примере показано, как создать цепочку ключей TCP-AO для аутентификации сеанс BGP или LDP.

В этом примере вы можете создать цепочку для ключей new_auth_key с 2 ключами, ключ 0 и ключ 1 на устройствах R1 и R2.

  1. Чтобы создать связку ключей new_auth_key с первым ключом ( ключ 0 ): Примечание:

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

    R1

      [редактировать безопасность] 
      user @ R1 # set authentication-key-chain key-chain  new_auth_key  key  0  secret  pAssWoRD123  start-time  2020-10-10.03:00  алгоритм  ao  ao-attribute идентификатор отправки  3  recv-id  8  криптографический алгоритм  hmac-sha-1-96  tcp-ao-option  включен  
     

    R2 (с обратными значениями send-id и recv-id )

      [редактировать безопасность] 
      user @ R2 # set authentication-key-chain key-chain  new_auth_key  key  0  secret  pAssWoRD123  start-time  2020-10-10.03: 00 алгоритм   ao  ao-attribute send-id  8  recv-id  3  криптографический алгоритм  hmac-sha-1-96  tcp-ao-option  включен  
     

    При настройке брелка учитывайте следующие параметры:

    Параметр

    Описание

    брелок

    Введите уникальное имя.

    ключ

    Введите уникальный идентификатор ключа.

    секрет

    Введите уникальный пароль.

    время начала

    Введите уникальное время в формате ГГГГ-ММ-ДД.ЧЧ: ММ , чтобы указать время начала ключа.

    алгоритм

    Введите алгоритм ao

    идентификатор отправки и идентификатор получения

    Введите любые два числа от 0 до 255.Ты не должен используйте эти числа для любого другого ключа в этой связке ключей.

    криптографический алгоритм

    Выберите hmac-sha-1-96 или aes-128-cmac-96 .

    tcp-ao-option

    Выберите включен , чтобы включить TCP-AO вариант.

  2. Чтобы добавить еще один ключ ( ключ 1 ), после создания ключа 0 :

    R1

     [редактировать цепочку ключей цепочки ключей аутентификации безопасности  new_auth_key ]
    user @ R1 #  установить ключ  1  секрет  sEcReT109  время начала  2020-11-11.04:00  алгоритм  ao  ao-attribute идентификатор отправки  1  recv-id  2  криптографический алгоритм  aes-128-cmac-96  tcp-ao-option  включен  
     

    R2 (с обратными значениями send-id и recv-id )

     [редактировать цепочку ключей цепочки ключей аутентификации безопасности  new_auth_key ]
    user @ R2 #  установить ключ  1  secret  sEcReT109  start-time  2020-11-11.04: 00  algorithm  ao  ao-attribute send-id  2  recv-id  1  cryptographic-algorithm  aes -128-cmac-96  tcp-ao-option  включен  
     
  3. Введите , зафиксируйте из режима конфигурации на обоих устройства для активации ваших изменений.
  4. Чтобы проверить связку ключей new_auth_key с двумя настроенными ключами, используйте команду show security authentication-key-chain из режима конфигурации.

    Ниже приведен пример вывода, основанный на этом примере:

      пользователь @ R1 # показать цепочки ключей аутентификации безопасности 
    key-chain new-auth_key {
        key 0 {
            секрет "$ ABC123"; ## СЕКРЕТНЫЕ ДАННЫЕ
            время начала «2020-10-10.03: 00: 00 -0700»;
            алгоритм ао;
            ao-attribute {
                идентификатор отправки 3;
                recv-id 8;
                tcp-ao-option включен;
                криптографический алгоритм hmac-sha-1-96;
            }
        }
    }
    key-chain new_auth_key {
        key 1 {
            секрет "$ FGh5435"; ## СЕКРЕТНЫЕ ДАННЫЕ
            время старта »2020-11-11.04:00:00 -0800 »;
            алгоритм ао;
            ao-attribute {
                идентификатор отправки 1;
                recv-id 2;
                tcp-ao-option включен;
                криптографический алгоритм aes-128-cmac-96;
            }
        }
    }
     

Вы успешно создали брелок!

Чтобы удалить связку ключей, используйте команду delete security authentication-key-chain key-chain key_chain имя команды из конфигурации режим.

Примечание:
  • Вы можете связать только одну цепочку ключей TCP-AO с BGP. или сеанс LDP в течение его срока службы.Вы не можете указать другой брелок к сеансу во время его жизни.

  • Мы рекомендуем минимальный интервал 30 минут между время начала любых двух последующих ключей в цепочке для ключей.

  • После того, как связка ключей настроена и используется TCP-соединением, вы не можете изменить значения send-id или recv-id активного ключа. Однако вы можете изменить другие параметры в ключ и любое новое соединение, связанное с обновленной связкой ключей примет обновленные параметры для установления соединения.

Для отображения информации о существующих связках ключей (если есть) из В рабочем режиме используйте команду show security keychain . Вот пример вывода:

  пользователь @ R1> показать цепочку ключей безопасности 
Допуск перехода связки ключей Active-ID Next-ID
                       Отправить Получить Отправить Отправить
 new-auth_key Нет Нет 0 0 2w0d 11:24 3600 (сек)
 new_auth_key Нет Нет 1 1 6w4d 11:24 3600 (сек) 

Заголовок аутентификации - обзор

Основы IPsec

Заголовок аутентификации (AH)

AH, один из протоколов безопасности IPSec, обеспечивает защиту целостности заголовков пакетов и данных, а также аутентификацию пользователя.Опционально он может обеспечивать защиту от воспроизведения и защиту доступа. AH не может зашифровать какую-либо часть пакетов.

Режимы AH

AH имеет два режима: транспорт и туннель . В туннельном режиме AH создает новый IP-заголовок для каждого пакета; в транспортном режиме AH не создает новый заголовок IP. В архитектурах IPSec, использующих шлюз, истинный IP-адрес источника или назначения для пакетов должен быть изменен на IP-адрес шлюза. Поскольку транспортный режим не может изменить исходный IP-заголовок или создать новый IP-заголовок, транспортный режим обычно используется в архитектурах «от хоста к хосту».

Инкапсуляция полезной нагрузки безопасности (ESP)

ESP - это второй базовый протокол безопасности IPSec. В первоначальной версии IPSec ESP предоставлял шифрование только для пакетных данных полезной нагрузки. При необходимости защита целостности обеспечивалась протоколом AH. Во второй версии IPSec ESP стал более гибким. Он может выполнять аутентификацию для обеспечения защиты целостности, но не для самого внешнего заголовка IP. Кроме того, шифрование ESP можно отключить с помощью алгоритма шифрования Null ESP.Следовательно, во всех реализациях IPSec, кроме самых старых, ESP может использоваться только для обеспечения шифрования; шифрование и защита целостности; или только защита целостности.

ESP имеет два режима: транспорт и туннель . В туннельном режиме ESP создает новый IP-заголовок для каждого пакета. В новом заголовке IP перечислены конечные точки туннеля ESP (например, два шлюза IPSec) в качестве источника и назначения пакета. Благодаря этому туннельный режим можно использовать со всеми тремя моделями архитектуры VPN.

Internet Key Exchange (IKE)

Назначение протокола Internet Key Exchange (IKE) - согласование, создание и управление ассоциациями безопасности. Ассоциация безопасности (SA) - это общий термин для набора значений, которые определяют функции и средства защиты IPSec, применяемые к соединению. SA также могут быть созданы вручную с использованием значений, заранее согласованных обеими сторонами, но эти SA не могут быть обновлены; этот метод не масштабируется для реальных крупномасштабных VPN. IKE использует пять различных типов обмена для создания сопоставлений безопасности, статуса передачи и информации об ошибках, а также для определения новых групп Диффи – Хеллмана.В IPSec IKE используется для обеспечения безопасного механизма для установления соединений, защищенных IPsec.

Протокол сжатия полезной нагрузки IP (IPComp)

При обмене данными часто желательно выполнять сжатие данных без потерь - для переупаковки информации в меньший формат без потери ее смысла. Протокол сжатия полезной нагрузки IP (IPComp) часто используется с IPSec. Если сначала применить IPComp к полезной нагрузке, а затем зашифровать пакет с помощью ESP, можно добиться эффективного сжатия.

IPComp можно настроить для обеспечения сжатия трафика IPSec, идущего только в одном направлении (например, сжимать пакеты от конечной точки A к конечной точке B, но не от конечной точки B к конечной точке A) или в обоих направлениях. Кроме того, IPComp позволяет администраторам выбирать из нескольких алгоритмов сжатия, включая DEFLATE и LZS. 49 IPComp предоставляет простое, но гибкое решение для сжатия полезных данных IPSec.

IPComp может обеспечить сжатие без потерь полезной нагрузки IPSec. Поскольку применение алгоритмов сжатия к определенным типам полезной нагрузки может фактически увеличить ее, IPComp сжимает полезную нагрузку только в том случае, если он действительно уменьшит размер пакета.

IPSec использует IKE для создания сопоставлений безопасности, которые представляют собой наборы значений, определяющих безопасность подключений, защищенных IPsec. Фаза 1 IKE создает IKE SA; Фаза 2 IKE создает IPSec SA через канал, защищенный IKE SA. Фаза 1 IKE имеет два режима: основной и агрессивный. В основном режиме согласовывается установление двунаправленной IKE SA с помощью трех пар сообщений, в то время как в агрессивном режиме используются только три сообщения. Хотя агрессивный режим быстрее, он менее гибкий и безопасный.Фаза 2 IKE имеет один режим: быстрый режим. В быстром режиме используются три сообщения для установления пары однонаправленных сопоставлений безопасности IPSec. Связь в быстром режиме шифруется методом, указанным в IKE SA, созданном на этапе 1.

Сеть 101: безопасность транспортного уровня (TLS) Сеть через браузер (O'Reilly)

Введение

Протокол SSL был первоначально разработан в Netscape для обеспечения безопасность транзакций электронной торговли в Интернете, которая требует шифрования для защищать личные данные клиентов, а также аутентификацию и целостность гарантии для обеспечения безопасной транзакции.Для этого SSL протокол был реализован на уровне приложений, непосредственно поверх TCP (Рисунок 4-1), что позволяет протоколы над ним (HTTP, электронная почта, обмен мгновенными сообщениями и многие другие) для работать без изменений, обеспечивая безопасность связи, когда общение по сети.

При правильном использовании SSL сторонний наблюдатель может только сделать вывод конечные точки подключения, тип шифрования, а также частоту и приблизительный объем отправленных данных, но не может читать или изменять какие-либо фактические данные.Рисунок 4-1. Безопасность транспортного уровня (TLS)

Когда протокол SSL был стандартизирован IETF, он был переименован. к безопасности транспортного уровня (TLS). Многие используют имена TLS и SSL взаимозаменяемы, но технически они разные, поскольку каждый описывает другую версию протокола.

SSL 2.0 был первой публично выпущенной версией протокола, но он был быстро заменен на SSL 3.0 из-за ряда обнаруженных средств защиты недостатки.Поскольку протокол SSL был проприетарным для Netscape, IETF предприняли попытку стандартизировать протокол, в результате чего появился RFC 2246, который был опубликован в январе 1999 года и стал известен как TLS 1.0. С затем IETF продолжил итерацию протокола для решения недостатки безопасности, а также расширение ее возможностей: TLS 1.1 (RFC 4346) был опубликован в апреле 2006 г., TLS 1.2 (RFC 5246) в августе 2008 г. и работает сейчас ведется определение TLS 1.3.

При этом не позволяйте обилию номеров версий вводить вас в заблуждение: ваши серверы всегда должны отдавать предпочтение и согласовывать последнюю стабильную версию протокола TLS для обеспечения максимальной безопасности, возможностей и гарантии исполнения.Фактически, некоторые критически важные для производительности функции, такие как как HTTP / 2, явно требует использования TLS 1.2 или выше и прерывает в противном случае связь. Хорошая безопасность и производительность идут рука об руку.

TLS был разработан для работы поверх надежного транспортного протокола. типа TCP. Однако он также был адаптирован для работы с дейтаграммами. протоколы, такие как UDP. Безопасность на транспортном уровне дейтаграмм (DTLS) протокол, определенный в RFC 6347, основан на протоколе TLS и может предоставить аналогичные гарантии безопасности при сохранении дейтаграммы модель доставки.

§Шифрование, аутентификация и целостность

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

Шифрование

Механизм скрытия того, что отправляется с одного хоста на другой.

Аутентификация

Механизм проверки действительности предоставленной идентификации материал.

Целостность

Механизм обнаружения фальсификации и подделки сообщений.

Чтобы установить криптографически безопасный канал данных, одноранговые узлы должны договориться о том, какие наборы шифров будут использоваться, и ключи, используемые для шифрования данных.Протокол TLS определяет четко определенный последовательность рукопожатия для выполнения этого обмена, которую мы рассмотрим в подробно в TLS Handshake. Гениальная часть этого рукопожатия и причина, по которой TLS работает в На практике это связано с использованием криптографии с открытым ключом (также известной как криптография с асимметричным ключом), что позволяет одноранговым узлам согласовывать общий секретный ключ без необходимости устанавливать какие-либо предварительные знания о каждом другое, и сделать это по незашифрованному каналу.

В рамках рукопожатия TLS протокол также позволяет обоим одноранговым узлам подтвердить свою личность. При использовании в браузере это механизм аутентификации позволяет клиенту проверить, что сервер кем он себя называет (например, ваш банк), а не просто притворяется быть местом назначения, подделав его имя или IP-адрес. Этот проверка основана на установленной цепочке доверия - см. Цепочка доверия и Центры сертификации.Кроме того, сервер также может опционально проверить личность клиента - например, прокси-сервер компании может аутентифицировать всех сотрудников, каждый из которых может иметь свой уникальный сертификат, подписанный компанией.

Наконец, с шифрованием и аутентификацией, протокол TLS также предоставляет собственный механизм кадрирования сообщений и подписывает каждое сообщение с кодом аутентификации сообщения (MAC). Алгоритм MAC является односторонним. криптографическая хеш-функция (фактически контрольная сумма), ключи к которой согласовываются обоими одноранговыми узлами.Всякий раз, когда отправляется запись TLS, Значение MAC создается и добавляется к этому сообщению, а получатель затем сможет вычислить и проверить отправленное значение MAC, чтобы гарантировать, что сообщение целостность и подлинность.

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

§Прокси, посредники, TLS и новые протоколы на Интернет

Расширяемость и успех HTTP создали яркую экосистема различных прокси и посредников в сети: кеш серверы, шлюзы безопасности, веб-ускорители, фильтры содержимого и многие другие другие. В некоторых случаях мы знаем об их присутствии (явное прокси), а в других полностью прозрачны до конца Пользователь.

К сожалению, сам успех и наличие этих серверов создал проблему для всех, кто пытается отклониться от HTTP / 1.Икс протокол любым способом: некоторые прокси-серверы могут просто передавать новый HTTP расширения или альтернативные форматы проводов, которые они не могут интерпретировать, другие могут продолжать слепо применять свою логику, даже если они не должны этого делать, и некоторые, такие как устройства безопасности, могут предполагать злонамеренный умысел, когда здесь ничего нет.

Другими словами, на практике отклонение от четко определенного семантика HTTP / 1.x на порту 80 часто приводит к ненадежным развертываниям: у некоторых клиентов нет проблем, у других же возникают непредсказуемые и непредсказуемые проблемы. трудно воспроизводимое поведение - e.g., один и тот же клиент может видеть разные поведения при перемещении между разными сетями.

Из-за такого поведения появились новые протоколы и расширения HTTP, такие как поскольку WebSocket, HTTP / 2 и другие должны полагаться на создание HTTPS туннель для обхода промежуточных прокси и обеспечения надежного модель развертывания: зашифрованный туннель скрывает данные от всех посредники. Если вы когда-нибудь задумывались, почему большинство руководств по WebSocket скажет вам использовать HTTPS для доставки данных мобильным клиентам, это Зачем.

§HTTPS везде

Незашифрованная связь - через HTTP и другие протоколы - создает большой количество уязвимостей конфиденциальности, безопасности и целостности. Такой обмены восприимчивы к перехвату, манипуляции и олицетворение и может раскрыть учетные данные пользователей, историю, личность и другая конфиденциальная информация. Наши приложения должны защищать себя, и наши пользователи против этих угроз путем доставки данных по HTTPS.

HTTPS защищает целостность веб-сайта

Шифрование предотвращает несанкционированное вмешательство злоумышленников в обмен данные - например, переписывание контента, внедрение нежелательных и вредоносных контент и так далее.

HTTPS защищает конфиденциальность и безопасность пользователя

Шифрование не позволяет злоумышленникам прослушивать обмен данные. Каждый незащищенный запрос может раскрыть конфиденциальную информацию о пользователь, и когда такие данные собираются по нескольким сеансам, может использоваться для деанонимности их личности и раскрытия других конфиденциальных Информация.Вся активность в браузере с точки зрения пользователя, следует считать конфиденциальными и конфиденциальными.

HTTPS обеспечивает широкие возможности в Интернете

Растущее число новых функций веб-платформы, таких как доступ геолокация пользователей, фотографирование, запись видео, включение офлайн взаимодействие с приложением и многое другое требует явного согласия пользователя, что в очередь, требует HTTPS. Предоставляемые гарантии безопасности и целостности по HTTPS - важные компоненты для обеспечения безопасности пользователя разрешение рабочего процесса и защита своих предпочтений.

Чтобы продолжить, как Internet Engineering Task Force (IETF) Совет по архитектуре Интернета (IAB) выпустил руководство для разработчиков и разработчиков протоколов, которые настоятельно рекомендуют HTTPS:

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

Стандарт только для HTTPS опубликованный Управлением управления и бюджета Белого дома, является отличный ресурс для получения дополнительной информации о необходимости HTTPS, и практические советы по его развертыванию.

§Давайте Зашифровать

Распространенное возражение и препятствие на пути к широкому распространению HTTPS был требованием для покупки сертификатов у одного из доверенные органы - см. Цепь доверия и Центры сертификации.Проект Let’s Encrypt запущен в 2015 году. решает эту конкретную проблему:

"Let’s Encrypt - бесплатный, автоматизированный и открытый сертификат. авторитет, предоставленный вам Исследовательской группой по интернет-безопасности (ISRG). Цель Let's Encrypt и протокола ACME - позволяют настроить HTTPS-сервер и получить его автоматически получить сертификат, доверенный браузеру, без участия человека вмешательство."

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

§TLS Рукопожатие

Прежде, чем клиент и сервер смогут начать обмен данными приложения через TLS необходимо согласовать зашифрованный туннель: клиент и сервер должен согласовать версию протокола TLS, выберите ciphersuite и при необходимости проверьте сертификаты.К сожалению, каждый из для этих шагов требуются новые пакеты (рис. 4-2) между клиентом и server, что увеличивает задержку запуска для всех TLS-подключений. Рисунок 4-2. Протокол рукопожатия TLS

Рисунок 4-2 предполагает то же (оптимистично) Задержка одностороннего "света в волокне" 28 миллисекунд между Новым Йорк и Лондон, как использовалось в предыдущем установлении TCP-соединения Примеры; см. Таблицу 1-1.

0 мс

TLS работает через надежный транспорт (TCP), что означает, что мы должны сначала завершите трехстороннее рукопожатие TCP, которое занимает одно полное поездка в оба конца.

56 мс

Установив TCP-соединение, клиент отправляет несколько спецификации в виде обычного текста, такие как версия протокола TLS он запущен, список поддерживаемых шифровальных наборов и другие TLS параметры, которые он может захотеть использовать.

84 мс

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

112 мс

Предполагая, что обе стороны могут согласовать общую версию и cipher, и клиент доволен сертификатом, предоставленным сервер, клиент инициирует либо RSA, либо ключ Диффи-Хеллмана обмен, который используется для установления симметричного ключа для следующая сессия.

140 мс

Сервер обрабатывает параметры обмена ключами, отправленные клиент, проверяет целостность сообщения, проверяя MAC, и возвращает encrypted Завершено сообщение клиенту.

168 мс

Клиент расшифровывает сообщение согласованным симметричным ключом, проверяет MAC, и если все в порядке, то туннель установлен и данные приложения теперь могут быть отправлены.

Как видно из приведенного выше обмена, для новых подключений TLS требуется два обходы для «полного рукопожатия» - это плохие новости. Однако в практика, оптимизированные развертывания могут работать намного лучше и обеспечивать согласованное рукопожатие 1-RTT TLS:

  • False Start - это расширение протокола TLS, которое позволяет клиенту и сервер, чтобы начать передачу зашифрованных данных приложения, когда рукопожатие завершено только частично - i.э., однажды ChangeCipherSpec и Finished сообщений отправлено, но не дожидаясь, пока другая сторона сделает то же самое. Этот оптимизация снижает накладные расходы на рукопожатие для новых подключений TLS к одна поездка туда и обратно; см. Включение ложного запуска TLS.

  • Если клиент ранее связывался с сервером, может использоваться «сокращенное рукопожатие», которое требует одного обхода и также позволяет клиенту и серверу снизить накладные расходы ЦП на повторное использование ранее согласованных параметров для безопасного сеанса; см. сеанс TLS Возобновление.

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

Одна из целей разработки TLS 1.3 заключается в уменьшении накладных расходов на задержку при настройке безопасного соединение: 1-RTT для новых и 0-RTT для возобновленных сеансов!

§RSA, Диффи-Хеллман и прямая секретность

По разным историческим и коммерческим причинам ЮАР рукопожатие было доминирующим механизмом обмена ключами в большинстве TLS развертывания: клиент генерирует симметричный ключ, шифрует его с помощью открытый ключ сервера и отправляет его на сервер для использования в качестве симметричного ключ для установленной сессии.В свою очередь, сервер использует свои частные ключ для расшифровки отправленного симметричного ключа, и обмен ключами завершен. С этого момента клиент и сервер используют согласованный симметричный ключ для шифрования их сеанса.

Рукопожатие RSA работает, но имеет критический недостаток: то же самое. пара открытого и закрытого ключей используется как для аутентификации сервера, так и для зашифровать симметричный сеансовый ключ, отправленный на сервер. В результате, если злоумышленник получает доступ к закрытому ключу сервера и прослушивает обмен, то они могут расшифровать весь сеанс.Даже хуже если злоумышленник в настоящее время не имеет доступа к закрытому ключу, он все еще может записать зашифрованный сеанс и расшифровать его позже как только они получат закрытый ключ.

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

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

Лучше всего то, что обмен ключами Диффи-Хеллмана может использоваться для уменьшения риск компрометации прошлых сеансов связи: мы можем создать новый "эфемерный" симметричный ключ как часть каждого обмена ключами и отбросьте предыдущие ключи. В результате, поскольку эфемерные ключи никогда не сообщаются и активно пересматриваются для каждого нового сеанс, в худшем случае злоумышленник может скомпрометировать клиент или сервер и получить доступ к ключам сеанса текущего и будущие сессии.Однако зная закрытый ключ или текущий эфемерный ключ, не помогает злоумышленнику расшифровать любой из предыдущих сеансы!

Комбинированный, использование обмена ключами Диффи-Хеллмана и эфемерный ключи сеансов обеспечивают "совершенную прямую секретность" (PFS): компромисс долгосрочных ключей (например, закрытого ключа сервера) не ставит под угрозу прошлые ключи сеанса и не позволяет злоумышленнику расшифровать ранее записанные сеансы. Очень желанная недвижимость, мягко говоря!

В результате, и это не должно вызывать удивления, RSA рукопожатие сейчас активно отменяется: все популярные браузеры предпочитают шифры, которые обеспечивают прямую секретность (т.е., положитесь на Обмен ключами Диффи-Хеллмана), и в качестве дополнительного стимула может включать определенные оптимизации протокола только тогда, когда прямая секретность доступно - например, Подтверждение связи 1-RTT через TLS False Start.

То есть обратитесь к документации по серверу, чтобы узнать, как включить и разверните прямую секретность! Еще раз, хорошая безопасность и производительность идти, держась за руки.

§Производительность открытого и симметричного ключа Криптография

Криптография с открытым ключом используется только во время начальной настройки Туннель TLS: сертификаты аутентифицируются и обмен ключами алгоритм выполняется.

Криптография с симметричным ключом, в которой используется установленный симметричный ключ. затем используется ключ для дальнейшего взаимодействия между клиентом и сервер в сеансе. В основном это делается для того, чтобы повысить производительность - криптография с открытым ключом - это гораздо больше вычислительно дорого. Чтобы проиллюстрировать разницу, если у вас есть OpenSSL установлен на вашем компьютере, вы можете запустить следующие тесты:

  • $> скорость openssl ecdh

  • $> скорость openssl aes

Обратите внимание, что единицы между двумя тестами не являются напрямую сравнимо: тест Диффи-Хеллмана на эллиптических кривых (ECDH) дает сводная таблица операций в секунду для разных размеров ключей, а Производительность AES измеряется в байтах в секунду.Тем не менее, это должно быть легко увидеть, что операции ECDH намного больше вычислительно дорого.

Точные значения производительности значительно различаются в зависимости от используемого оборудование, количество ядер, версия TLS, конфигурация сервера и другие факторы. Не поддавайтесь устаревшим тестам! Всегда запускайте тесты производительности на вашем собственном оборудовании и обратитесь к разделу «Уменьшение вычислительных ресурсов». Затраты на дополнительный контекст.

§ Согласование протокола уровня приложений (ALPN)

Два сетевых узла могут захотеть использовать собственный протокол приложения для общаться друг с другом.Один из способов решить эту проблему - определить заранее назначьте ему известный порт (например, порт 80 для HTTP, порт 443 для TLS) и настройте все клиенты и серверы для использования Это. Однако на практике это медленный и непрактичный процесс: каждый назначение портов должно быть одобрено и, что еще хуже, межсетевые экраны и другие посредники часто разрешают трафик только на порты 80 и 443.

В результате, чтобы обеспечить простое развертывание пользовательских протоколов, мы должны повторно использовать порты 80 или 443 и использовать дополнительный механизм для согласования протокол приложения.Порт 80 зарезервирован для HTTP, а HTTP спецификация предоставляет специальный поток Upgrade для этого очень цель. Однако использование Upgrade может добавить дополнительные сетевой обход задержки, и на практике часто ненадежен в наличие множества посредников; см. Прокси, Посредники, TLS и новые протоколы в Интернете.

Решение, как вы уже догадались, использовать порт 443, который зарезервирован. для безопасных сеансов HTTPS, работающих через TLS.Использование сквозного зашифрованный туннель скрывает данные от промежуточных прокси и обеспечивает быстрый и надежный способ развертывания новых протоколов приложений. Однако нам все еще нужен другой механизм для согласования протокола, который будет использоваться в сеансе TLS.

Application Layer Protocol Negotiation (ALPN), как следует из названия, - это расширение TLS, которое удовлетворяет эту потребность. Расширяет TLS рукопожатие (рисунок 4-2) и позволяет партнерам согласовывать протоколы без дополнительных обходов.В частности, процесс выглядит следующим образом:

  • Клиент добавляет новое поле ProtocolNameList , содержащий список поддерживаемых протоколов приложений, в Сообщение ClientHello .

  • Сервер проверяет поле ProtocolNameList и возвращает поле ProtocolName , указывающее выбранный протокол как часть сообщения ServerHello .

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

§История и взаимосвязь NPN и ALPN

Next Protocol Negotiation (NPN) - это расширение TLS, которое разработан в рамках программы SPDY в Google, чтобы обеспечить эффективную согласование протокола приложения во время рукопожатия TLS. Звук знакомые? Конечный результат функционально эквивалентен ALPN.

ALPN - это пересмотренная и одобренная IETF версия расширения NPN. В NPN сервер объявлял, какие протоколы он поддерживает, а Затем клиент выбрал и подтвердил протокол.В ALPN этот обмен было отменено: теперь клиент указывает, какие протоколы он поддерживает, Затем сервер выбирает и подтверждает протокол. Обоснование изменение состоит в том, что это приводит к более близкому согласованию ALPN с другие стандарты согласования протоколов.

Короче говоря, ALPN является преемником NPN.

§Имя сервера Индикация (СНИ)

Зашифрованный туннель TLS может быть установлен между любыми двумя TCP одноранговые узлы: клиенту необходимо знать только IP-адрес другого однорангового узла. чтобы установить соединение и выполнить рукопожатие TLS.Однако что, если сервер хочет разместить несколько независимых сайтов, каждый со своим Сертификат TLS на том же IP-адресе - как это работает? Обманывать вопрос; это не так.

Для решения предыдущей проблемы используется указание имени сервера (SNI). в протокол TLS было введено расширение, которое позволяет клиенту чтобы указать имя хоста, к которому клиент пытается подключиться как часть рукопожатия TLS. В свою очередь, сервер может проверять SNI. имя хоста, отправленное в сообщении ClientHello , выберите соответствующий сертификат и завершите рукопожатие TLS для желаемого хозяин.

§TLS, HTTP и Выделенные IP-адреса

Рабочий процесс TLS + SNI идентичен заголовку Host реклама в HTTP, где клиент указывает имя хоста сайт, который он запрашивает: один и тот же IP-адрес может содержать много разных домены, и оба SNI и Host необходимы для устранить неоднозначность между ними.

К сожалению, некоторые старые клиенты (например, большинство запущенных версий IE в Windows XP, Android 2.2 и другие) не поддерживают SNI. Как результат, если вам нужно предоставить TLS таким клиентам, то вам может понадобиться выделенный IP-адрес для каждого хоста.

§ Возобновление сеанса TLS

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

§Идентификаторы сеанса

Первый механизм возобновления идентификаторов сеанса (RFC 5246) был введен в SSL 2.0, что позволило серверу создавать и отправлять 32-байтовый идентификатор сеанса как часть ServerHello сообщение во время полного согласования TLS, которое мы видели ранее. С идентификатор сеанса на месте, и клиент, и сервер могут хранить предварительно согласованные параметры сеанса - с ключом по идентификатору сеанса - и повторное использование их для последующего сеанса.

В частности, клиент может включить идентификатор сеанса в ClientHello сообщение, чтобы указать серверу, что он все еще помнит согласованный набор шифров и ключи из предыдущих рукопожатие и может использовать их повторно. В свою очередь, если сервер может найти параметры сеанса, связанные с объявленным идентификатором, в его cache, тогда может произойти сокращенное рукопожатие (рис. 4-3). В противном случае полный требуется согласование нового сеанса, которое приведет к созданию нового сеанса Я БЫ.Рисунок 4-3. Сокращенное рукопожатие TLS протокол

Использование идентификаторов сеанса позволяет нам удалить полный цикл обмена, а также накладные расходы на криптографию с открытым ключом, которая используется для согласовать общий секретный ключ. Это позволяет обеспечить безопасное соединение. устанавливается быстро и без потери безопасности, поскольку мы повторно используем ранее согласованные данные сеанса.

Возобновление сеанса - важная оптимизация как для HTTP / 1.Икс и развертывания HTTP / 2. Сокращенное рукопожатие исключает полное круговая задержка и значительно снижает вычислительные затраты для обеих сторон.

Фактически, если браузеру требуется несколько подключений к одному и тому же хост (например, когда используется HTTP / 1.x), он часто намеренно ждет для завершения первого согласования TLS перед открытием дополнительных подключения к тому же серверу, чтобы их можно было "возобновить" и повторно использовать те же параметры сеанса.Если вы когда-нибудь смотрели в сети проследить и задаться вопросом, почему вы редко видите несколько TLS на одном хосте переговоры в полете, вот почему!

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

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

§Билеты на сеанс

Для решения этой проблемы при развертывании сеанса TLS на стороне сервера. кеши, механизм замены "Session Ticket" (RFC 5077) был введено, что устраняет требование к серверу сохранять состояние сеанса для каждого клиента.Вместо этого, если клиент указывает, что он поддерживает билеты сеанса, сервер может включать New Session Запись билета , которая включает все согласованные данные сеанса зашифровано секретным ключом, известным только серверу.

Этот билет сеанса затем сохраняется клиентом и может быть включен в расширении SessionTicket внутри ClientHello сообщение следующего сеанса. Таким образом, все данные сеанса хранятся только на клиенте, но билет по-прежнему в безопасности потому что он зашифрован ключом, известным только серверу.

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

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

§Цепь Доверительных и Сертификационных центров

Аутентификация является неотъемлемой частью установления каждого TLS. связь.Ведь можно вести разговор за зашифрованный туннель с любым партнером, включая злоумышленника, и если мы не сможем убедитесь, что хозяин, с которым мы говорим, тот, которому мы доверяем, тогда все работа по шифрованию могла быть напрасной. Чтобы понять, как мы можем проверить идентичность партнера, давайте рассмотрим простой рабочий процесс аутентификации между Алисой и Бобом:

  • И Алиса, и Боб генерируют свои собственные открытый и закрытый ключи.

  • И Алиса, и Боб скрывают свои закрытые ключи.

  • Алиса делится своим открытым ключом с Бобом, а Боб - с Алиса.

  • Алиса создает новое сообщение для Боба и подписывает его. закрытый ключ.

  • Боб использует открытый ключ Алисы для проверки предоставленного сообщения. подпись.

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

Затем Алиса получает сообщение от Чарли, с которым она никогда не встречалась, но который утверждает, что является другом Боба.Фактически, чтобы доказать, что он дружив с Бобом, Чарли попросил Боба подписать свой открытый ключ с помощью Боба. закрытый ключ и прикрепил эту подпись к своему сообщению (рис. 4-4). В этом случае Алиса сначала проверяет Подпись Боба на ключе Чарли. Она знает открытый ключ Боба и поэтому возможность проверить, действительно ли Боб подписал ключ Чарли. Потому что она доверяет Решение Боба проверить Чарли, она принимает сообщение и выполняет аналогичная проверка целостности сообщения Чарли, чтобы убедиться, что это так, действительно, от Чарли.Рисунок 4-4. Цепочка доверия для Алисы, Боб, и Чарли

Мы только что создали цепочку доверия: Алиса доверяет Боб, Боб доверяет Чарли, и в результате транзитивного доверия Алиса решает доверять Чарли. Пока никто в цепочке не скомпрометирован, это позволяет нам создавать и расширять список доверенных лиц.

Аутентификация в Интернете и в вашем браузере выполняется точно так же процесс, как показано. Это означает, что на этом этапе вы должны спросить: кому доверяет ваш браузер и кому вы доверяете, когда используете браузер? На этот вопрос есть как минимум три ответа:

Сертификаты, указанные вручную

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

Центры сертификации

Центр сертификации (ЦС) - это доверенная третья сторона, которая доверяет как субъект (владелец) сертификата, так и сторона полагаясь на сертификат.

Браузер и операционная система

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

На практике было бы непрактично хранить и вручную проверять каждый и каждый ключ для каждого веб-сайта (хотя вы можете, если так наклонный). Следовательно, наиболее распространенным решением является использование сертификата. органы (ЦС), которые выполняют эту работу за нас (рис. 4-5): браузер указывает, каким ЦС доверять (корневые центры сертификации), а затем на них ложится бремя проверки каждого сайта, который они подписать, а также проверить и убедиться, что эти сертификаты не используются неправомерно или скомпрометирован.Если безопасность любого сайта с сертификатом ЦС нарушено, то этот ЦС также обязан отозвать скомпрометированный сертификат. Рисунок 4-5. Подписание ЦС цифровых сертификаты

Каждый браузер позволяет вам проверять цепочку доверия вашего безопасного соединение (рис. 4-6), обычно доступное, щелкнув на значке замка рядом с URL-адресом. Рисунок 4-6. Цепочка сертификатов доверия для igvita.com (Google Chrome, версия 25)

  • igvita.com сертификат подписан StartCom Class 1 Primary Промежуточный сервер.

  • Сертификат первичного промежуточного сервера StartCom класса 1 подписан Центром сертификации StartCom.

  • StartCom Certification Authority - это признанный корневой сертификат власть.

"Якорем доверия" для всей цепочки является корневой сертификат. авторитет, которым в только что показанном случае является Сертификат StartCom Власть.Каждый браузер поставляется с предварительно инициализированным списком доверенных центры сертификации ("корни"), и в этом случае браузер доверяет и может проверить корневой сертификат StartCom. Следовательно, через транзитивная цепочка доверия к браузеру, поставщику браузера и Центр сертификации StartCom, мы расширяем доверие до места назначения сайт.

§Прозрачность сертификата

Каждый поставщик операционной системы и каждый браузер предоставляют общедоступную список всех центров сертификации, которым они доверяют по умолчанию.Использовать ваша любимая поисковая система, чтобы найти и исследовать эти списки. В практики, вы обнаружите, что большинство систем полагается на сотни проверенных центры сертификации, что также является частой жалобой на система: большое количество доверенных центров сертификации создает большую поверхность для атак область против цепочки доверия в вашем браузере.

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

§Отмена сертификата

Иногда издателю сертификата необходимо отозвать или признать сертификат недействительным по ряду возможных причин: закрытый ключ сертификата был скомпрометирован, сертификат сам авторитет был скомпрометирован, или из-за множества более мягких такие причины, как заменяющий сертификат, изменение принадлежности и т. д. на. Для решения этой проблемы сами сертификаты содержат инструкции (Рисунок 4-7) о том, как проверьте, не были ли они отозваны.Следовательно, чтобы гарантировать, что цепочка доверия не скомпрометирован, каждый одноранговый узел может проверить статус каждого сертификата с помощью следуя встроенным инструкциям вместе с подписями, так как это проверяет цепочку сертификатов. Рисунок 4-7. Инструкции CRL и OCSP для igvita.com (Google Chrome, версия 25)

§Сертификат Список отзыва (CRL)

Список отозванных сертификатов (CRL) определен RFC 5280 и определяет простой механизм проверки статуса каждого сертификата: каждый центр сертификации ведет и периодически публикует список серийных номеров отозванных сертификатов.Любой, кто пытается подтвердить сертификат затем может загрузить список отзыва, кэшировать его и проверьте наличие в нем определенного серийного номера - если он присутствует, то он был отозван.

Этот процесс прост и понятен, но он имеет ряд ограничения:

  • Растущее число отзывов означает, что список CRL будет становятся только длиннее, и каждый клиент должен получить весь список серийные номера.

  • Нет механизма мгновенного уведомления о сертификате отзыв - если CRL был кэширован клиентом до сертификат был отозван, то CRL будет считать отозванным сертификат действителен до истечения срока действия кеша.

  • Необходимость получить последний список CRL из CA может блокировать проверка сертификата, которая может значительно увеличить задержку Рукопожатие TLS.

  • Получение CRL может завершиться ошибкой по разным причинам, и в таких случаях поведение браузера не определено. Большинство браузеров рассматривают такие случаев как «мягкий сбой», позволяя продолжить проверку - да, ой.

§Онлайн Протокол статуса сертификата (OCSP)

Чтобы устранить некоторые ограничения механизма CRL, Online Протокол статуса сертификата (OCSP) был введен RFC 2560, который предоставляет механизм для выполнения проверки в реальном времени статуса сертификат.В отличие от файла CRL, который содержит все отозванные серийные номера номеров, OCSP позволяет клиенту запрашивать базу данных сертификатов CA непосредственно для только серийного номера, о котором идет речь, при проверке цепочка сертификатов.

В результате механизм OCSP потребляет меньше полосы пропускания и может для обеспечения проверки в реальном времени. Однако требование выполнить Запросы OCSP в реальном времени создают свой собственный набор проблем:

  • CA должен быть в состоянии обрабатывать нагрузку запросов в реальном времени.

  • Центр сертификации должен гарантировать, что служба работает и доступна по всему миру. всегда.

  • Запросы OCSP в реальном времени могут нарушить конфиденциальность клиента, поскольку CA знает, какие сайты посещает клиент.

  • Клиент должен блокировать запросы OCSP во время проверки цепочка сертификатов.

  • Поведение браузера снова не определено и обычно приводит к «мягкому сбою», если выборка OCSP завершается неудачно из-за сети тайм-аут или другие ошибки.

В качестве реальной точки данных телеметрия Firefox показывает, что OCSP время ожидания запросов составляет 15% времени, и добавьте примерно 350 мс до подтверждения TLS в случае успеха - см. Hpbn.co/ocsp-performance.

§ Сшивание OSSP

По причинам, указанным выше, ни отзыва CRL, ни OSCP механизмы предлагают гарантии безопасности и производительности, которые мы желаем для наших приложений.Однако не отчаивайтесь, ведь сшивание OCSP (RFC 6066, расширение «Запрос статуса сертификата») адресовано большинству проблемы, которые мы видели ранее, разрешив выполнение проверки сервер и будет отправлен ("скреплен") как часть рукопожатия TLS на клиент:

  • Вместо клиента, отправляющего запрос OCSP, это сервер который периодически извлекает подписанный OCSP с отметкой времени ответ от CA.

  • Затем сервер добавляет (т. Е. «Скрепляет») подписанный OCSP. ответ как часть рукопожатия TLS, позволяя клиенту проверить как сертификат, так и приложенный отзыв OCSP запись, подписанная CA.

Эта смена ролей безопасна, поскольку скрепленная запись подписана ЦС и может быть проверен клиентом, и предлагает ряд важные преимущества:

  • Клиент не пропускает историю переходов.

  • Клиенту не нужно блокировать и запрашивать сервер OCSP.

  • Клиент может завершить обработку отзыва, если сервер opts-in (путем рекламы флага OSCP "Must-Staple") и проверка не удалась.

Короче говоря, чтобы получить как лучшую безопасность, так и гарантии производительности, не забудьте настроить и протестировать сшивание OCSP на своих серверах.

§ Протокол записи TLS

В отличие от уровней IP или TCP ниже, все данные обмениваются внутри Сеанс TLS также создается с использованием четко определенного протокола (рис. 4-8). Запись TLS протокол отвечает за идентификацию различных типов сообщений (рукопожатие, предупреждение или данные через поле «Тип содержимого»), а также защита и проверка целостности каждого сообщения. Рисунок 4-8. Структура записи TLS

Типичный рабочий процесс для доставки данных приложения выглядит следующим образом:

  • Протокол записи принимает данные приложения.

  • Полученные данные разбиваются на блоки: максимум 2 14 байт или 16 КБ на запись.

  • Код аутентификации сообщения (MAC) или HMAC добавляется к каждой записи.

  • Данные в каждой записи зашифрованы с использованием согласованного шифра.

По завершении этих шагов зашифрованные данные передаются в уровень TCP для транспорта.На принимающей стороне тот же рабочий процесс, но в обратном порядке применяется одноранговым узлом: расшифровать запись с использованием согласованного зашифровать, проверить MAC, извлечь и доставить данные в приложение, указанное выше Это.

Хорошая новость заключается в том, что вся только что показанная работа выполняется TLS. сам слой и полностью прозрачен для большинства приложений. Однако, протокол записи вводит несколько важных выводов, которые мы нужно знать:

  • Максимальный размер записи TLS составляет 16 КБ.

  • Каждая запись содержит 5-байтовый заголовок, MAC (до 20 байтов для SSLv3, TLS 1.0, TLS 1.1 и до 32 байтов для TLS 1.2) и заполнение если используется блочный шифр.

  • Чтобы расшифровать и проверить запись, вся запись должна быть имеется в наличии.

Выбор правильного размера записи для вашего приложения, если у вас есть возможность сделать это может быть важной оптимизацией. Небольшие записи влекут за собой большие накладные расходы ЦП и байтов из-за кадрирования записи и проверки MAC, тогда как большие записи должны быть доставлены и собраны заново Уровень TCP, прежде чем они могут быть обработаны уровнем TLS и доставлены в ваше приложение - перейдите к разделу "Оптимизация размера записи TLS, чтобы получить полный доступ" подробности.

§Оптимизация для TLS

Для развертывания вашего приложения через TLS потребуется дополнительная работа, как внутри вашего приложения (например, перенос ресурсов на HTTPS, чтобы избежать смешанный контент), а также от конфигурации инфраструктуры отвечает за доставку данных приложения по TLS. Хорошо настроенный развертывание может иметь огромное положительное значение в наблюдаемых производительность, удобство использования и общие эксплуатационные расходы. Давай нырнем в.

§Сокращение вычислений Стоит

Создание и поддержка зашифрованного канала вводит дополнительные вычислительные затраты для обоих партнеров. В частности, сначала существует асимметричное (с открытым ключом) шифрование, используемое во время TLS рукопожатие (объяснил TLS Handshake). Затем, когда общий секрет установлен, он используется как симметричный ключ для шифрования всех записей TLS.

Как мы уже отмечали ранее, криптография с открытым ключом требует больше вычислений. дорого по сравнению с криптографией с симметричным ключом, а в первые дни Интернета часто требовали дополнительного оборудования для выполнения «Разгрузка SSL."Хорошая новость в том, что в этом больше нет необходимости и то, что когда-то требовало специального оборудования, теперь можно сделать прямо на ЦПУ. Крупные организации, такие как Facebook, Twitter и Google, которые предлагать TLS миллиардам пользователей, выполнять все необходимые TLS переговоры и вычисления в программном обеспечении и на серийном оборудовании.

В январе этого года (2010 г.) Gmail перешел на использование HTTPS для все по умолчанию. Ранее он был представлен как вариант, но теперь все наши пользователи используют HTTPS для защиты своей электронной почты между их браузерами и Google, все время.Для этого нам не пришлось развертывать никаких дополнительных машин и специального оборудования. На на наших производственных интерфейсных машинах SSL / TLS составляет менее 1% загрузки ЦП, менее 10 КБ памяти на одно соединение и менее более 2% накладных расходов сети. Многие считают, что SSL / TLS требует много процессорного времени, и мы надеемся, что предыдущие цифры (общедоступны для первый раз) поможет это развеять.

Если вы перестанете читать сейчас, вам нужно запомнить только одно: SSL / TLS больше не требует больших вычислительных затрат.

Адам Лэнгли (Google)

Мы развернули TLS в большом масштабе, используя как оборудование, так и программные балансировщики нагрузки. Мы обнаружили, что современные программные TLS реализации, работающие на обычных процессорах, достаточно быстры, чтобы справиться с высокая нагрузка HTTPS-трафика без необходимости использования выделенных криптографическое оборудование. Мы обслуживаем весь наш HTTPS-трафик, используя программное обеспечение, работающее на серийном оборудовании.

Дуг Бивер (Facebook)

Эллиптическая кривая Диффи-Хеллмана (ECDHE) - это всего лишь немного больше. дороже RSA для эквивалентного уровня безопасности… На практике развертывания, мы обнаружили, что включение и определение приоритета шифра ECDHE наборы фактически привели к незначительному увеличению использования ЦП. HTTP сообщения поддержки активности и возобновление сеанса означают, что большинство запросов не требуется полное рукопожатие, поэтому операции рукопожатия не доминируют в нашем Использование процессора.Мы обнаружили, что 75% клиентских запросов Twitter пересылаются соединения установлены с помощью ECDHE. Остальные 25% составляют в основном это старые клиенты, которые еще не поддерживают шифр ECDHE апартаменты.

Джейкоб Хоффман-Эндрюс (Twitter)

Чтобы добиться наилучших результатов в собственных развертываниях, извлеките максимум из Сессия TLS Возобновление - разверните, оцените и оптимизируйте процент успеха. Устранение необходимости выполнять дорогостоящую криптографию с открытым ключом операции при каждом рукопожатии значительно уменьшат как вычислительные затраты и время ожидания TLS; нет причин тратить CPU циклы работы, которую вам не нужно делать.

Говоря об оптимизации циклов ЦП, убедитесь, что ваши серверы в актуальном состоянии с последней версией библиотек TLS! Кроме того к улучшениям безопасности, вы также часто будете видеть производительность преимущества. Безопасность и производительность идут рука об руку.

§Включить 1-RTT TLS Рукопожатия

Неоптимизированное развертывание TLS может легко добавить много дополнительных туда и обратно и вводят значительную задержку для пользователя - e.г. рукопожатие с несколькими RTT, медленный и неэффективный отзыв сертификата проверки, большие записи TLS, требующие многократного обращения и т. д. Не будь тем сайтом, ты можешь сделать намного лучше.

Хорошо настроенное развертывание TLS должно добавить не более дополнительных туда и обратно для согласования TLS-соединения, независимо от независимо от того, является ли он новым или возобновленным, и избегайте всех других ловушек, связанных с задержкой: настроить возобновление сеанса и включить прямую секретность, чтобы включить TLS Фальстарт.

Чтобы получить наилучшую сквозную производительность, обязательно проведите аудит обоих собственные и сторонние сервисы и серверы, используемые вашим приложением, включая вашего провайдера CDN. Для быстрого обзора табеля успеваемости популярные серверы и CDN, посетите istlsfastyet.com.

§Оптимизировать повторное использование подключения

Лучший способ минимизировать задержку и вычислительные затраты настройка новых соединений TCP + TLS предназначена для оптимизации повторного использования соединений.Таким образом снижаются затраты на установку по запросам и обеспечивается значительная более быстрый опыт для пользователя.

Убедитесь, что настройки вашего сервера и прокси-сервера позволяют соединения keepalive и аудит настроек тайм-аута соединения. Многие популярные серверы устанавливают агрессивные тайм-ауты соединения (например, некоторые Apache версии по умолчанию имеют таймаут 5 секунд), что заставляет много ненужных повторные переговоры. Для достижения наилучших результатов используйте свои журналы и аналитику, чтобы определить оптимальные значения тайм-аута.

§Предприятие Раннее Прекращение действия

Как мы обсуждали в Primer on Latency and Пропускная способность, мы не сможем ускорить передачу наших пакетов, но мы можем заставить их пройти меньшее расстояние. Разместив наш "край" серверов ближе к пользователю (рис. 4-9), мы можем значительно уменьшить время приема-передачи и общая стоимость рукопожатий TCP и TLS. Рисунок 4-9. Досрочное увольнение клиента связи

Простым способом добиться этого является использование услуг сеть доставки контента (CDN), которая поддерживает пулы пограничных серверов по всему миру или развернуть свой собственный.Позволяя пользователю разорвать соединение с ближайшим сервером, вместо того, чтобы пересекать через океаны и континентальные ссылки на вашу страну происхождения, клиент получает преимущество «досрочного прекращения» с более короткими поездками туда и обратно. Эта техника одинаково полезен и важен как для статического, так и для динамического контента: static контент также может кэшироваться и обслуживаться пограничными серверами, тогда как динамические запросы могут быть перенаправлены по установленным соединениям из край к исходной точке.

§ Некэшированная исходная выборка

Метод использования CDN или прокси-сервера для получения ресурс, который может потребоваться настроить для каждого пользователя или содержит другие частные данные, и, следовательно, не является глобально кешируемым ресурсом на edge, обычно известен как «некэшируемая исходная выборка».

Хотя сети CDN работают лучше всего, когда данные кэшируются в географически распределенном серверов по всему миру, некэшированная исходная выборка по-прежнему обеспечивает очень важная оптимизация: клиентское соединение прерывается с соседний сервер, который может значительно сократить рукопожатие затраты на задержку.В свою очередь, CDN или ваш собственный прокси-сервер может поддерживать "теплый пул соединений" для передачи данных источнику серверов, что позволяет быстро вернуть ответ клиенту.

Фактически в качестве дополнительного уровня оптимизации некоторые CDN провайдеры будут использовать соседние серверы на обеих сторонах соединения! Клиентское соединение разрывается на ближайшем узле CDN, который затем передает запрос узлу CDN, расположенному близко к источнику, и затем запрос направляется к источнику.Переход в сети CDN позволяет маршрутизировать трафик по оптимизированной магистрали CDN, что может помочь еще больше уменьшить задержку между клиентом и источником серверы.

§Настройка кэширования сеанса и возобновления без сохранения состояния

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

Идентификаторы сеанса, от которых зависит кеширование сеанса TLS, были введены в SSL 2.0 и имеют широкую поддержку среди большинства клиентов и серверы. Однако, если вы настраиваете TLS на своем сервере, не Предположим, что поддержка сеанса будет включена по умолчанию. На самом деле это больше Обычно он отключен на большинстве серверов по умолчанию, но вам виднее! Дважды проверьте и проверьте конфигурацию вашего сервера, прокси и CDN:

  • Серверы с несколькими процессами или рабочими должны использовать общий кеш сеанса.

  • Размер общего кеша сеанса должен быть настроен в соответствии с вашими уровнями трафика.

  • Должен быть указан период ожидания сеанса.

  • В конфигурации с несколькими серверами маршрутизация одного и того же IP-адреса клиента или одного и того же Идентификатор сеанса TLS на один и тот же сервер - это один из способов обеспечить использование кеша сеанса.

  • Если "липкая" балансировка нагрузки невозможна, общий кеш должен использоваться между разными серверами для обеспечения хорошего сеанса использование кеша, и необходимо установить безопасный механизм для обмена и обновления секретных ключей для расшифровки предоставленного сеанса Билеты.

  • Проверяйте и отслеживайте статистику кеширования сеансов TLS для наилучшего представление.

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

§Включение ложного запуска TLS

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

Чтобы получить лучшее из обоих миров - рукопожатие в оба конца для новых и повторные посетители и экономия вычислительных ресурсов для повторных посетителей - мы можем используйте TLS False Start, которое является дополнительным расширением протокола, позволяет отправителю отправлять данные приложения (рис. 4-10), когда рукопожатие только частично завершено.Рисунок 4-10. Рукопожатие TLS с False Начинать

False Start не изменяет протокол рукопожатия TLS, а скорее влияет только на время протокола, когда данные приложения могут быть послал. Интуитивно понятно, как только клиент отправил ClientKeyExchange запись, она уже знает шифрование ключ и может начать передачу данных приложения - остальную часть рукопожатие проводится для подтверждения того, что никто не вмешивался в записи рукопожатия, которые могут выполняться параллельно.В результате False Пуск позволяет нам сохранить рукопожатие TLS за один проход независимо от того, от того, выполняем ли мы полное или сокращенное рукопожатие.

§Развертывание TLS Ложь Старт

Потому что False Start только изменяет время рукопожатия протокол, он не требует никаких обновлений самого протокола TLS и может быть реализован в одностороннем порядке, то есть клиент может просто начать передача зашифрованных данных приложения раньше.Ну вот и теория.

На практике, даже если TLS False Start должен быть обратным совместим со всеми существующими клиентами и серверами TLS, что позволяет по умолчанию для всех подключений TLS оказалось проблематичным из-за некоторых плохо реализованные сервера. В результате все современные браузеры может использовать TLS False Start, но будет делать это только при определенных условия соблюдаются сервером:

  • Chrome и Firefox требуют объявления протокола ALPN для присутствовать в рукопожатии сервера, и что набор шифров выбранный сервером обеспечивает прямую секретность.

  • Safari требует, чтобы набор шифров, выбранный сервером обеспечивает прямую секретность.

  • Internet Explorer использует комбинацию черного списка известных сайты, которые ломаются при включении TLS False Start, и тайм-аут для повторения рукопожатия, если квитирование TLS False Start не удалось.

Чтобы включить ложный запуск TLS во всех браузерах, сервер должен рекламировать список поддерживаемых протоколов через расширение ALPN - e.г., "h3, http / 1.1" - и должен быть настроен для поддержки и предпочтения наборов шифров. которые обеспечивают прямую секретность.

§Оптимизировать размер записи TLS

Все данные приложения, доставляемые через TLS, переносятся в протокол записи (рисунок 4-8). Максимальный размер каждого размер записи составляет 16 КБ, и в зависимости от выбранного шифра каждая запись будет добавить от 20 до 40 байтов служебных данных для заголовка, MAC и необязательная прокладка.Если после этого запись помещается в один TCP-пакет, тогда мы также должны добавить служебные данные IP и TCP: 20-байтовый заголовок для IP и 20-байтовый заголовок для TCP без параметров. В результате есть потенциальная нагрузка от 60 до 100 байтов для каждой записи. Для типичный максимальный размер блока передачи (MTU) 1500 байт на провода, эта структура пакета переводит как минимум 6% кадрирования накладные расходы.

Чем меньше запись, тем выше накладные расходы на кадрирование.Однако, просто увеличить размер записи до максимального размера (16 КБ) - это не обязательно хорошая идея. Если запись охватывает несколько пакетов TCP, тогда уровень TLS должен дождаться прибытия всех пакетов TCP, прежде чем он может расшифровать данные (рис. 4-11). Если какой-либо из этих пакетов TCP получит потерян, переупорядочен или задросселирован из-за контроля перегрузки, тогда отдельные фрагменты записи TLS необходимо буферизовать перед их можно декодировать, что приводит к дополнительной задержке.На практике, эти задержки могут создать значительные узкие места для браузера, которые предпочитает использовать данные в потоковом режиме. Рисунок 4-11. WireShark захватывает 11211-байтовая запись TLS, разделенная на 8 сегментов TCP

Маленькие записи несут накладные расходы, большие записи вызывают задержку, и там нет единственного значения для "оптимального" размера записи. Вместо этого для Интернета приложения, которые использует браузер, лучшая стратегия - для динамической регулировки размера записи в зависимости от состояния TCP связь:

  • Если соединение новое и окно перегрузки TCP низкое, или когда соединение какое-то время простаивало (см. Медленный старт Restart), каждый пакет TCP должен содержать ровно одну запись TLS, и запись TLS должна занимать полный максимальный размер сегмента (MSS), выделенный TCP.

  • Когда окно перегрузки соединения велико, и если мы передача большого потока (например, потокового видео), размер запись TLS может быть увеличена для охвата нескольких пакетов TCP (до 16 КБ), чтобы уменьшить нагрузку на кадры и ЦП на клиенте и сервере.

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

Использование динамической стратегии обеспечивает наилучшую производительность для интерактивный трафик: небольшой размер записи исключает ненужную буферизацию задержка и улучшает время до первого - {HTML-байт,…, видео frame} , а больший размер записи оптимизирует пропускную способность за счет минимизация накладных расходов TLS для долгоживущих потоков.

Чтобы определить оптимальный размер записи для каждого состояния, начнем с начальный случай нового или незанятого TCP-соединения, когда мы хотим избежать Записи TLS из нескольких пакетов TCP:

  • Выделите 20 байтов для служебных данных кадрирования IPv4 и 40 байтов для IPv6.

  • Выделите 20 байтов для служебных данных кадрирования TCP.

  • Выделите 40 байтов для служебных данных опций TCP (отметки времени, SACK).

Если исходный MTU составляет 1500 байт, остается 1420 байт. для записи TLS, доставленной по IPv4, и 1400 байт для IPv6. Быть в будущем используйте размер IPv6, который оставляет нам 1400 байт для каждую запись TLS и при необходимости отрегулируйте, если ваш MTU ниже.

Затем решение о том, когда следует увеличить размер записи. и сбросить, если соединение было бездействующим, может быть установлено на основе предварительно настроенные пороги: увеличьте размер записи до 16 КБ после X КБ данных было перенесено, и сбросить запись размер после Y миллисекунд простоя.

Обычно мы не можем настроить размер записи TLS. управление на прикладном уровне.Вместо этого часто это настройка и иногда постоянная времени компиляции для вашего TLS-сервера. Проверить документации вашего сервера для получения подробной информации о том, как настроить эти значения.

§ Оптимизация TLS в Google

По состоянию на начало 2014 г. серверы Google используют небольшие записи TLS, которые подходят в один сегмент TCP для первого 1 МБ данных, увеличьте запись размер до 16 КБ после этого для оптимизации пропускной способности, а затем сбросить размер записи обратно в один сегмент после одной секунды бездействие - вспенить, сполоснуть, повторить.

Аналогично, если ваши серверы обрабатывают большое количество TLS соединений, то минимизация использования памяти для каждого соединения может быть жизненная оптимизация. По умолчанию популярные библиотеки, такие как OpenSSL будет выделять до 50 КБ памяти на каждое соединение, но, как и в случае размер записи, возможно, стоит проверить документацию или источник код для настройки этого значения. Серверы Google сокращают свои Буферы OpenSSL уменьшаются примерно до 5 КБ.

§Оптимизировать Цепочка сертификатов

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

Как браузер узнает, откуда брать недостающие сертификаты? Каждый дочерний сертификат обычно содержит URL-адрес для родитель. Если URL-адрес опущен, а требуемый сертификат не указан включен, то проверка не удастся.

И наоборот, не включайте ненужные сертификаты, такие как доверенные корни в вашей цепочке сертификатов - они добавляют ненужные байты. Напомним, что цепочка сертификатов сервера отправляется как часть TLS. рукопожатие, которое, вероятно, происходит через новое TCP-соединение, которое на ранних этапах своего алгоритма медленного старта.Если сертификат размер цепочки превышает начальное окно перегрузки TCP, тогда мы будем непреднамеренно добавить дополнительные обходы к рукопожатию TLS: длина сертификата переполнит окно перегрузки и вызовет сервер, чтобы остановить и дождаться подтверждения клиента перед продолжением.

На практике размер и глубина цепочки сертификатов были очень значительными. большие проблемы и проблемы со старыми стеками TCP, которые инициализировали свои начальное окно перегрузки до 4 сегментов TCP - см. Медленный запуск.Для новее развертываний, начальное окно перегрузки увеличено до 10 TCP сегментов и должно быть более чем достаточно для большинства сертификатов цепи.

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

§Настройка сшивания OCSP

Каждое новое соединение TLS требует, чтобы браузер проверял подписи отправленной цепочки сертификатов.Однако есть еще одно важный шаг, который мы не можем забыть: браузер также должен проверять что сертификаты не отозваны.

Для проверки статуса сертификата браузер может использовать один из несколько методов: Список отозванных сертификатов (CRL), Статус онлайн-сертификата Протокол (OCSP) или OCSP Сшивание. У каждого метода есть свои ограничения, но OCSP Stapling обеспечивает, безусловно, лучшие гарантии безопасности и производительности - см. подробности в предыдущих разделах.Обязательно настройте свои серверы на включить (скрепить) ответ OCSP от CA к предоставленному цепочка сертификатов. Это позволит браузеру выполнить проверка отзыва без дополнительных сетевых обходов и с улучшенными гарантии безопасности.

  • ответов OCSP могут иметь размер от 400 до 4000 байт. Привязка этого ответа к вашей цепочке сертификатов увеличит его size - обратите особое внимание на общий размер сертификата. цепочка, чтобы она не переполняла начальное окно перегрузки для новых TCP-соединений.

  • Текущие реализации OCSP Stapling допускают только один OCSP ответ должен быть включен, что означает, что браузеру, возможно, придется откат к другому механизму отзыва, если ему нужно проверить другие сертификаты в цепочке - сократите длину своего цепочка сертификатов. В будущем OCSP Multi-Stapling должен решить эту конкретную проблему.

Самые популярные серверы поддерживают сшивание OCSP.Проверить соответствующие документация по поддержке и инструкции по настройке. Аналогично, если используя или выбирая CDN, убедитесь, что их стек TLS поддерживает и настроен на использование сшивания OCSP.

§Включить строгую транспортную безопасность HTTP (HSTS)

HTTP Strict Transport Security - важная политика безопасности механизм, который позволяет источнику объявлять правила доступа совместимому браузер через простой HTTP-заголовок, например « Strict-Transport-Security: max-age = 31536000 ".В частности, он инструктирует пользовательского агента, чтобы соблюдать следующие правила:

  • Все запросы к источнику следует отправлять по HTTPS. Этот включает как навигацию, так и все другие подресурсы того же происхождения запросы - например, если пользователь вводит URL без префикса https пользовательский агент должен автоматически преобразовать его в запрос https; если страница содержит ссылку на не-https ресурс, пользователь агент должен автоматически преобразовать его, чтобы запросить версию https.

  • Если безопасное соединение не может быть установлено, пользователь не разрешено обойти предупреждение и запросить версию HTTP, т.е. источник только HTTPS.

  • max-age указывает время жизни указанного HSTS набор правил в секундах (например, max-age = 31536000 равно 365-дневному время жизни для рекламируемой политики).

  • includeSubdomains указывает, что политика должна применяется ко всем субдоменам текущего происхождения.

HSTS преобразует источник в пункт назначения, поддерживающий только HTTPS, и помогает защитить приложение от множества пассивных и активных сетей атаки. В качестве дополнительного бонуса он также предлагает хорошую производительность. оптимизация за счет устранения необходимости перенаправления HTTP-to-HTTPS: клиент автоматически перезаписывает все запросы в безопасный источник перед они отправлены!

Обязательно тщательно протестируйте развертывание TLS перед включением HSTS.После кэширования политики клиентом невозможность согласования Подключение TLS приведет к серьезному отказу, т. Е. пользователь увидит страницу с ошибкой браузера, и продолжить работу не удастся. Это поведение явный и необходимый выбор дизайна для предотвращения сетевых атак от обмана клиентов для получения доступа к вашему сайту без HTTPS.

Список предварительной загрузки §HSTS

Механизм HSTS оставляет самый первый запрос источнику незащищены от активных атак - e.г. злонамеренная сторона могла понизить рейтинг запроса клиента и предотвратить регистрацию Политика HSTS. Чтобы решить эту проблему, большинство браузеров предоставляют отдельный HSTS список предварительной загрузки ", который позволяет источнику запрашивать включен в список сайтов с поддержкой HSTS, которые поставляются с браузер.

Когда вы будете уверены в развертывании HTTPS, подумайте о добавление вашего сайта в список предварительной загрузки HSTS через hstspreload.appspot.com.

§Включить HTTP Закрепление открытого ключа (HPKP)

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

Компрометация центра сертификации DigiNotar является одним из несколько громких примеров, когда злоумышленник смог выдать и использовать поддельные, но действительные сертификаты против сотен известных места.

Public Key Pinning позволяет сайту отправлять HTTP-заголовок, который указывает браузерам запомнить (закрепить) один или несколько сертификатов в свою цепочку сертификатов. Поступая таким образом, он может определить, какие сертификаты или эмитенты должны приниматься браузером на последующие посещения:

  • Источник может закрепить свой листовой сертификат.Это самый безопасная стратегия, потому что вы, по сути, жестко кодируете небольшой набор специальных подписей сертификатов, которые должны быть приняты браузер.

  • Источник может закрепить один из родительских сертификатов в цепочка сертификатов. Например, начало координат может закрепить промежуточный сертификат своего ЦС, который сообщает браузеру, что для этого конкретного происхождения, он должен доверять только сертификатам, подписанным этим конкретный центр сертификации.

Выбор правильной стратегии, для каких сертификатов закреплять, какие и сколько резервных копий предоставить, продолжительность и другие критерии для развертывания HPKP важны, детализированы и выходят за рамки нашего обсуждения. Проконсультируйтесь с вашей любимой поисковой системой или вашим местным гуру безопасности, чтобы узнать, больше информации.

HPKP также предоставляет режим «только отчет», который не обеспечивает принудительное выполнение предоставлен PIN-код, но может сообщать об обнаруженных сбоях.Это может быть отличный первый шаг к валидации вашего развертывания и служит механизм выявления нарушений.

§Обновить содержимое сайта на HTTPS

Для обеспечения максимальной безопасности и производительности критически важно что сайт фактически использует HTTPS для получения всех своих ресурсов. В противном случае мы столкнемся с рядом проблем, которые поставят под угрозу оба или хуже, сломайте сайт:

  • Смешанный «активный» контент (например,г. поставлены скрипты и таблицы стилей через HTTP) будет заблокирован браузером и может нарушить функциональность сайта.

  • Смешанный «пассивный» контент (например, изображения, видео, аудио и т. Д., доставляется через HTTP) будет получен, но позволит злоумышленнику наблюдать и делать выводы о действиях пользователей, а также снижать производительность требующие дополнительных подключений и рукопожатий.

Аудит вашего контента и обновление ваших ресурсов и ссылок, включая сторонний контент, чтобы использовать HTTPS.Механизм политики безопасности контента (CSP) может окажут здесь большую помощь, как для выявления нарушений HTTPS, так и для обеспечения соблюдения желаемая политика.

Content-Security-Policy: обновления-небезопасные-запросы
Content-Security-Policy-Report-Only: default-src https :;
  report-uri https://example.com/reporting/endpoint
 
  1. Указывает браузеру обновить все (собственные и сторонние) запросы к HTTPS.

  2. Указывает браузеру сообщать о любых нарушениях, не связанных с HTTPS, на назначенная конечная точка.

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

§ Контрольный список для выполнения

Как разработчики приложений мы защищены от большинства сложность протокола TLS - клиент и сервер выполняют большую часть тяжелая работа от нашего имени.Однако, как мы видели в этой главе, это не означает, что мы можем игнорировать аспекты производительности наших приложения через TLS. Настройка наших серверов для включения критически важного TLS оптимизации и настройки наших приложений, чтобы клиент мог Воспользуйтесь такими функциями, чтобы получить высокие дивиденды: более быстрое рукопожатие, уменьшенная задержка, лучшие гарантии безопасности и многое другое.

Имея это в виду, краткий контрольный список для включения в повестку дня:

  • Получите максимальную производительность от TCP; см. Оптимизация для TCP.

  • Обновите библиотеки TLS до последней версии и (пере) соберите серверы против них.

  • Включите и настройте кэширование сеанса и возобновление без сохранения состояния.

  • Отслеживайте процент попаданий в кэширование сеанса и настраивайте конфигурацию соответственно.

  • Настройте шифры прямой секретности, чтобы включить ложный запуск TLS.

  • Завершайте сеансы TLS ближе к пользователю, чтобы минимизировать круговые обходы задержки.

  • Используйте динамическое изменение размера записи TLS для оптимизации задержки и пропускная способность.

  • Проверяйте и оптимизируйте размер вашей цепочки сертификатов.

  • Настройте сшивание OCSP.

  • Настройте HSTS и HPKP.

  • Настройте политики CSP.

  • Включить HTTP / 2; см. HTTP / 2.

§Тестирование и проверка

Наконец, чтобы проверить и протестировать вашу конфигурацию, вы можете использовать онлайн сервис, такой как Qualys SSL Server Протестируйте ваш общедоступный сервер на предмет общей конфигурации и безопасности. недостатки. Кроме того, вам следует ознакомиться с интерфейс командной строки openssl , который поможет вам проверить все рукопожатие и конфигурация вашего сервера локально.

    $> openssl s_client -state -CAfile root.ca.crt -connect igvita.com:443 

  ПОДКЛЮЧЕНО (00000003)
  SSL_connect: до инициализации / подключения
  SSL_connect: SSLv2 / v3 пишет клиенту привет A
  SSL_connect: SSLv3 читает сервер привет A
  глубина = 2 / C = IL / O = StartCom Ltd./OU=Secure Digital Certificate Signing
          / CN = Центр сертификации StartCom
  проверить возврат: 1
  глубина = 1 / C = IL / O = StartCom Ltd./OU=Secure Digital Certificate Signing
          / CN = ЦС первичного промежуточного сервера StartCom класса 1
  проверить возврат: 1
  глубина = 0 / описание = ABjQuqt3nPv7ebEG / C = США
          / CN = www.igvita.com/[email protected]
  проверить возврат: 1
  SSL_connect: SSLv3 читать сертификат сервера A
  SSL_connect: сервер чтения SSLv3 выполнен A
  SSL_connect: SSLv3 записывает обмен ключами клиента A
  SSL_connect: спецификация шифра изменения записи SSLv3 A
  SSL_connect: запись SSLv3 завершена A
  SSL_connect: данные сброса SSLv3
  SSL_connect: чтение SSLv3 завершено A
  ---
  Цепочка сертификатов
   0 с: / description = ABjQuqt3nPv7ebEG / C = US
       /CN=www.igvita.com/[email protected]
     i: / C = IL / O = StartCom Ltd./OU=Secure Digital Certificate Signing
       / CN = ЦС первичного промежуточного сервера StartCom класса 1
   1 с: / C = IL / O = StartCom Ltd./ OU = Безопасная подпись цифрового сертификата
       / CN = ЦС первичного промежуточного сервера StartCom класса 1
     i: / C = IL / O = StartCom Ltd./OU=Secure Digital Certificate Signing
       / CN = Центр сертификации StartCom
  ---
  Сертификат сервера
  ----- НАЧАТЬ СЕРТИФИКАТ -----
  ... отрезать ...
  ---
  Имена ЦС сертификатов клиента не отправлены
  ---
  Рукопожатие SSL прочитало 3571 байт и записало 444 байта
  ---
  Новый, TLSv1 / SSLv3, шифр RC4-SHA
  Открытый ключ сервера - 2048 бит
  Поддерживается безопасное повторное согласование
  Сжатие: НЕТ
  Расширение: НЕТ
  SSL-сессия:
      Протокол: TLSv1
      Шифр: RC4-SHA
      Идентификатор сеанса: 269349C84A4702EFA7...
      Идентификатор сеанса-ctx:
      Мастер-ключ: 1F5F5F33D50BE6228A ...
      Key-Arg: Нет
      Время начала: 1354037095
      Тайм-аут: 300 (сек)
      Проверить код возврата: 0 (ок)
  ---
 
  1. Клиент завершил проверку полученной цепочки сертификатов.

  2. Цепочка полученных сертификатов (два сертификата).

  3. Размер полученной цепочки сертификатов.

  4. Выданный идентификатор сеанса для возобновления TLS с отслеживанием состояния.

В предыдущем примере мы подключаемся к igvita.com через порт TLS по умолчанию (443) и выполните рукопожатие TLS. Поскольку s_client не делает предположения об известных корневых сертификатах, вручную указываем путь к корневому сертификату, который на момент написания является StartSSL Центр сертификации для примера домена.В вашем браузере уже есть общие корневые сертификаты и, таким образом, может проверять цепочку, но s_client не делает таких предположений. Попробуйте опустить корень сертификат, и вы увидите в журнале ошибку проверки.

Проверка цепочки сертификатов показывает, что сервер отправил два сертификаты, которые в сумме составляют 3571 байт. Также мы можем видеть согласованные переменные сеанса TLS - выбранный протокол, шифр, ключ - и мы можем также убедитесь, что сервер выдал идентификатор сеанса для текущего сессия, которая может быть возобновлена ​​в будущем.

Довольно хорошая проверка подлинности пакетов

Довольно хорошая проверка подлинности пакетов Довольно хорошая аутентификация пакетов

Андреас Хеберлен 1,2 Родриго Родригес 1 Кришна Гуммади 1 Питер Друшель 1
1 Институт программных систем Макса Планка (MPI-SWS) 2 Университет Райса

Аннотация

Интернет-адреса обычно используются для определения личность лиц, отправляющих оскорбительный трафик - a возможности, для обеспечения которых они не были предназначены.В результате проблемы в изобилии: обвиняются невиновные пользователи, в то время как виновные могут легко избежать обнаружения.

В этой статье мы представляем Pretty Good Packet Authentication (PGPA), простой сервис, который может установить, хост отправил определенный пакет. PGPA обеспечивает прочную основу чтобы действовать против виновного, и в то же время это позволяет невиновным пользователям, чтобы защитить себя от ложных обвинений. Мы тоже описать реализацию PGPA, которая может быть развернута постепенно и с минимальными изменениями в существующем Интернете.

1 Введение

В Интернете отсутствует механизм надежной проверки источника доставленный пакет. Тем не менее, исходный IP-адрес в пакете обычно используется для определения личности ответственного конечного узла для отправки пакета. Интернет-провайдеры, спам-фильтры и брандмауэры используют IP. адресов в черный список и заблокировать трафик от скомпрометированного или вредоносные конечные узлы [8]. Кроме того, закон правоохранительные органы начали использовать IP-адреса источника пакетов в качестве доказательства при судебном преследовании пользователей, которые якобы распространяют защищенные или незаконный контент за Интернет [5,7].Однако недавние инциденты показывают, что полагаться на IP-адреса для определения источник интернет-трафика.

С одной стороны, поскольку IP-адреса в Интернете можно легко подделать, злоумышленники могут использовать поддельные адреса, чтобы избежать обнаружения. На самом деле это Хорошо известно, что уязвимости в протоколе междоменной маршрутизации BGP, может использоваться для перехвата целых IP-префиксов на короткие периоды время. Угонщик может отправлять и получать трафик из захваченного пула. IP-адресов за это время.Например, недавнее исследование электронный спам показал, что некоторые спамеры используют эту технику для работы вокруг IP-адресов, внесенных в черный список [8]. Хуже, при нынешнем положении дел жертва могла быть ложно обвиняется и привлекается к ответственности за действия злоумышленника.

Недавно исследователи Вашингтонского университета продемонстрировали потенциал для таких ложных обвинений, вызывая сотни DMCA для нескольких машин, которые не были участие в сетях обмена файлами, включая собственный принтер и точка доступа к сети [7].В более серьезный случай, невиновный пользователь подозревался в загрузке детская порнография, потому что его интернет-провайдер ошибся при поиске IP-адрес полиции. К тому времени, как ошибка была обнаружена, полиция уже конфисковала его компьютеры и обыскала его дом [5].

С другой стороны, если ошибочный пакет действительно имеет правильный адрес отправителя, отправитель может использовать слабость текущего механизм как отговорка. Поскольку нельзя быть уверенным в том, что пакет исходный IP-адрес был подделан или нет, настоящий отправитель может правдоподобно отрицать отправив пакет.Таким образом, трудно привлечь к ответственности пользователей. за свои действия.

В этой статье мы представляем систему под названием Pretty Good Packet. Проверка подлинности (PGPA) , которая решает эти проблемы, предлагая сервис простой пакетной аутентификации. PGPA определяет будь то хост H отправил определенный пакет P примерно в момент времени t . Это создает прочную основу для действий против владельцев. хостов, которые отправляют вредоносный или незаконный трафик, поскольку они не могут дольше отрицать отправку или использовать отсутствие надежной аутентификации как оправдание.В то же время PGPA может установить, что подозреваемый устройство имеет , а не , отправивший конкретный пакет, что дает невиновность пользователям возможность защитить себя от ложных обвинений.

В отличие от систем, предназначенных для онлайн-проверки источник трафика [1], PGPA аутентифицирует пакеты не только получателям, но и всем, у кого есть доступ к их. Например, системный администратор может использовать перехваченные пакеты, чтобы убедить полицию, что некий пользователь пытался взломать одну из его систем, и полиция может запросить PGPA, чтобы проверить его утверждения.С помощью системы онлайн-проверки перехваченный пакет не будет убедительным доказательством, потому что обвиняемый пользователь мог утверждать, что исходный адрес был подделан администратор.

PGPA также защищает конфиденциальность пользователей. Поскольку PGPA отвечает только на запросы о конкретных пакетах и ​​конкретных моментах времени, его нельзя использовать для слежки за трафиком пользователя или для проверки трафика пользователя на предмет подозрительное поведение. Чтобы получить полезную информацию из PGPA, запрашивающий должен быть либо получателем рассматриваемых пакетов, или он должен был перехватить их или получить их от получатель.Во всех случаях содержимое пакетов и предполагаемое источник уже известен запрашивающему; PGPA просто подтверждает подлинность исходного адреса.

С одной стороны, PGPA - это простой сервис; он не пытается соответствовать функциональности полноценных систем подотчетности, таких как AIP [1]. С другой стороны, у него есть преимущество. быть намного проще в развертывании, чем решение с чистого листа. Мы показываем что PGPA может быть реализован при доступе пользователя в Интернет ссылка, не требуя изменений в маршрутизаторах или в Интернете backbone, и что его можно постепенно развертывать.

Остальная часть этой статьи структурирована следующим образом. Даем краткий обзор и обсудим соответствующую работу в Разделе 2, мы опишем реализацию PGPA в разделе 3, а несколько приложений мы обсудим в разделе 4. В Разделе 5 мы завершаем работу и кратко опишем будущую работу.

2 Обзор и сопутствующие работы

В этом разделе мы даем краткий обзор аутентификации пакетов, и обсуждаем сопутствующие работы.

2.1 Пакетная аутентификация

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

Мы предлагаем более слабую форму аутентификации пакетов, которая позволяет Интернет-провайдер, чтобы проверить, был ли отправлен данный недавно переданный IP-пакет одним из своих клиентов.Говоря точнее, PGPA предоставляет следующие возможности:

Дан пакет P с исходным IP-адресом S и метка времени t , провайдер, которому принадлежит S , может проверить, S отправил P примерно в t .

Мы покажем, что эта возможность может быть реализована и развернута в прямолинейный способ.

2.2 Предыдущие работы

Предыдущие системы предлагали приблизительные решения для этого проблема.В частности, отслеживание IP системы [9,10] могут определить источник сетевого трафика; однако им требуются маршрутизаторы для маркировки пакетов и / или хранения информации о них. Это бы вовлечь серьезные изменения в существующие сети, которые мы пытаемся избегать.

По другой связанной теме, подотчетность в Интернете была предлагается как способность связать действие с ответственным юридическое лицо. Подотчетный Интернет-протокол (AIP) [1] заменяет IP, который позволяет хостам и доменам доказать, что они владеют адресом они используют.Основываясь на этом фундаменте, протокол направлен на решение подмена источника, подмена маршрута и отказ в обслуживании (DoS). Однако, AIP - это проект с чистого листа, развертывание которого потребует обновления. основные компоненты Интернета, включая сетевой протокол и структура адресации.

В этой статье мы останавливаемся на более узкой цели: проверить, что пакет был отправлен с хоста, чей IP-адрес указан в заголовок. Мы показываем, что эта простая возможность может быть развернута достаточно легко и по-прежнему обладает мощными свойствами.

Рисунок 1: Пример настройки PGPA. Устройство PGPA хранит дайджест пакеты, которые передает клиент. Учитывая пакет и приблизительное время передачи, он может проверить, пакет подлинный.

2.3 Как будет работать система PGPA?

Пакетная аутентификация по существу требует настройки устройства, которое отслеживает переданные пакеты. Где в сети разместить это устройство? Естественный выбор - за ссылка доступа, то есть связь между клиентом и его интернет-провайдером (рисунок 1).Здесь настоящая личность клиента известна из его договор с интернет-провайдером, и устройство может наблюдать за всем трафиком клиента.

Развертывание пакетной аутентификации на каналах доступа имеет три различных преимущества. Во-первых, он не требует обновлений или дополнительных обработка в высокоскоростной магистрали. Во-вторых, помогает против спуфинг на стороне клиента, потому что интернет-провайдер знает, какие IP-адреса имеют назначен каждой ссылке (например, через DHCP) и может отфильтровать любые пакеты с разными адресами.Наконец, он предусматривает инкрементное развертывание, так как каждая ссылка доступа может быть обновлена независимо. Это дает нам реальный путь развертывания.

2.4 Достаточно ли PGPA?

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

2,5 Кому можно доверять?

Мы предполагаем, что интернет-провайдеры, участвующие в PGPA, не вступают в сговор с клиенты. Это предположение необходимо, потому что интернет-провайдер может разрешить клиент может отправлять пакеты способом, который обходит PGPA, делая его выглядят так, как если бы у пакета был поддельный IP-адрес.Мы считаем, что это разумное предположение, что авторитетные интернет-провайдеры не защищают активно злонамеренные клиенты. Если известно, что некоторые интернет-провайдеры не заслуживают доверия, это необходимо учитывать при оценке их Ответы PGPA.

Другой вопрос, следует ли доверять провайдеру клиенты не обвиняют их (случайно или намеренно) в пакетах они фактически не отправляли. Это зависит от того, как реализована PGPA; мы обсудим детали в разделе 3.2.

3 Внедрение PGPA

В этом разделе мы описываем простую систему, которая реализует PGPA в современная архитектура Интернета.

3.1 Монитор трафика

PGPA требует нового типа промежуточного ящика под названием traffic monitor , который записывает информацию о пакетах, которые были переданы по заданному ссылка для доступа. Для каждого пакета монитор трафика вычисляет дайджест и отметка времени, и он записывает их на встроенное запоминающее устройство. Когда пользователь обвиняемый в отправке незаконных или оскорбительных сообщений, обвинитель должен предъявить по крайней мере один пакет в качестве доказательства вместе с приблизительным временем его коробка передач.Затем провайдер запрашивает у монитора трафика дайджест, который совпадает с доказательствами. Если такой дайджест найден и его временная метка близка достаточно, пользователь несет ответственность за трафик.

3.2 Расположение монитора

Монитор трафика можно установить на любом конце линии доступа, то есть либо на территории пользователя, либо у провайдера. Установка монитор в помещении пользователя может быть более масштабируемым и менее дорогим для интернет-провайдера. Кроме того, пользователю не обязательно доверять Интернет-провайдер, потому что он может установить устройство мониторинга от поставщика, которому доверяет.С другой стороны, если монитор находится под контролем пользователя, провайдер должен запретить пользователям обходить мониторинг устройство. Интернет-провайдер может добиться этого установив безопасный канал к монитору и только прием трафика по этому каналу. Например, секретный ключ может быть разделяется между монитором и интернет-провайдером, и устройство может добавить MAC для каждого пакета, который он отправляет интернет-провайдеру. Для защиты от взлома, устройство может стереть ключевой материал, когда обнаружит, что корпус был открыт.

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

3.3 Расчет дайджестов

Монитор хранит дайджесты, а не полные пакеты.Дайджесты достаточно для проверки наличия или отсутствия определенного пакета, и они не раскрывают содержимое других переданных пакетов. Однако мы должны быть осторожны при вычислении дайджеста, потому что в IP сети, некоторые поля заголовка пакета могут изменяться по пути, такие как TTL и контрольная сумма. Чтобы предотвратить ложные негативы, потому что хэш пакета доказательства не соответствует записанному хешу, монитор маскирует эти поля перед вычислением хэша, например, используя методика, представленная в [10].

Пакеты также могут быть преобразованы посредством IP-фрагментации. А простой способ справиться с фрагментацией - собрать монитор заново исходящие пакеты перед вычислением их дайджестов и разрешить PGPA запрашивает только полные пакеты. Если наблюдатель перехватывает пакет фрагменты, он должен собрать соответствующие пакеты и выпустить Запрос PGPA для повторно собранного пакета.

3.4 Требования к хранению

С ограниченным объемом памяти монитор может хранить свои записи только в течение ограниченного количества время.Этого достаточно, потому что хеши нужно хранить только до тех пор, пока сначала предъявляется обвинение; старые хеши можно удалить. Если длительная аутентификация требуется, монитор может отвечать на запросы с помощью подписанного сертификата, который затем остается в силе, даже если исходные записи больше не доступны.

Недорогого жесткого диска должно хватить почти для любого доступа ссылки - тем более, что большинство соединений асимметричны и имеют малая пропускная способность вверх по течению. Сегодня первоклассные DSL-соединения имеют пропускная способность 1 Мбит / с, поэтому они могут передавать не более 3,125 40-байтных пакетов в секунду.(Это соответствует подтверждению TCP; данные пакетов обычно намного больше.) Следовательно, даже под предположения наихудшего случая, 187 ГБ жесткого диска достаточно для хранения Хеш SHA-1 и 32-битная метка времени за месяц. Кроме того, поскольку емкость хранилища росла быстрее, чем пропускная способность [3], будущие технологии будут стремиться позволяют хранить необходимые данные как можно дольше периоды. Имея хранилище в ссылка доступа становится все более распространенной; поставщики услуг уже развертывание управляемых устройств, таких как шлюзы TriplePlay или телеприставки коробки [6], многие из которых уже включать запоминающее устройство значительной емкости.

3.5 Предотвращение утечки информации

Потенциальная проблема с PGPA заключается в том, что он может ненадлежащим образом утечка информации о трафике пользователей. Например, предположим, что злоумышленник хотел знать, заходил ли пользователь в определенную сеть сайт. Может ли злоумышленник просто угадать несколько пакетов, которые пользователь отправил бы на сайт, если бы он получил к нему доступ (например, TCP пакеты подтверждения на порт 80), а затем запросите PGPA, чтобы узнать, какой из этих пакетов действительно был отправлен?

Шансы на успех такой атаки невелики, потому что злоумышленнику придется угадывать не только все содержимое пакет - включая "случайные" поля, такие как порядковый номер TCP, номер подтверждения TCP и идентификатор IP, но также примерное время его передачи.PGPA должна позволять небольшое время окно при проверке меток времени; ведь есть задержки в очереди и часы в Интернете синхронизируются слабо, поэтому мы не можем ожидайте, что запрашивающая сторона узнает точное время, когда пакет был послал. Однако это окно может быть небольшим, порядка секунд. Злоумышленнику будет сложно правильно угадать все вышеуказанных полей заголовка (80 бит) плюс приблизительное время коробка передач. Кроме того, монитор может вносить дополнительную случайность. заменив IP-идентификатор или добавив параметр заголовка на случайное значение.Наконец, скорость, с которой монитор отвечает на запросы, может быть ограниченным, чтобы предотвратить поисковые атаки.

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

3,6 Гарантии

По сравнению с нашим первоначальным определением PGPA в Разделе 2.1, монитор трафика вводит два практических ограничения.Во-первых, из-за конечной емкости хранилища монитор может предоставлять информацию только о пакетах не старше определенное количество времени T max , скажем, один месяц. Это должно быть приемлемо на практике, если проступки обычно можно обнаружить в течение этого времени. Во-вторых, система может отвечать на запросы только тогда, когда монитор развернут на ссылка доступа предполагаемого отправителя.

Таким образом, гарантия, которую мы достигаем, такова: для пакета P , метка времени t, которая не более T max в прошлом , а исходный IP-адрес S , интернет-провайдер, которому принадлежит S может проверить, отправил ли S P приблизительно в момент времени t , предоставлено что мониторы развернуты на каналах доступа провайдера.

4 Приложения PGPA

Далее мы обсуждаем приложения и варианты использования предлагаемого IP-пакета. средство аутентификации.

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

Например, интернет-провайдеры часто получают жалобы на нарушение авторских прав. владельцев или правоохранительных органов, утверждая, что один из интернет-провайдеров клиенты участвовали в незаконной деятельности в Интернете и требуя, чтобы интернет-провайдер раскрыл личность клиента, связанного с с заданным IP-адресом.Сегодня интернет-провайдерам приходится принимать такие требования лицом к лицу. ценить и раскрывать личность клиента. Когда обвинение превращается неверно, это может быть трагично для покупателя и неудобно для интернет-провайдера. Например, среди многих недавних случаев IP адрес, который был причастен к скачиванию материала, защищенного авторским правом из BitTorrent оказался принтером [7]. С помощью средство аутентификации пакетов, провайдер может проверить, обоснованно. Может потребовать представить пакетную трассировку нарушающего трафика. и проверьте, найдены ли совпадающие хеш-значения в связанном клиентском трафике переваривать.

PGPA также может быть использован для улучшения существующих схем смягчения отрицания. сервисных атак. Например, была предложена услуга `` заткнись '', который позволяет хосту D запрашивать конкретный хост S , который отправляет трафик на D нельзя отправлять дальше трафик [4]. Пакетная аутентификация может использоваться для проверять такие запросы, тем самым предотвращая злоупотребление служба.

С точки зрения клиента, аутентификация IP-пакетов обеспечивает защита от ложных обвинений.Мы уже упоминали о дело [5], где невиновный пользователь был обвинен в хранении скачал детскую порнографию. Пакетная аутентификация позволила бы Интернет-провайдер пользователя, чтобы установить, что вредоносный трафик не был отправлен своего покупателя, и тем самым уберечь его от ложных обвинений и клеветы. Даже в случае технической ошибки, такой как перепутанный IP-адрес, пользователь мог легко доказать свою невиновность, согласившись на осмотр его монитора устройства.

Наконец, PGPA может служить зданием блок для глобальной службы аутентификации IP-пакетов, которая позволяет кто угодно в Интернете, чтобы проверить подлинность любого IP-пакета они получают.Служба позволит хостам представлять произвольные IP-пакет и спросите, подлинный ли пакет. Служба будет определить ISP (AS), ответственного за IP-адрес источника пакета, и запросить систему PGPA этого интернет-провайдера. Сервис отвечает указание на `` подлинность '' (т. е. совпадающий дайджест пакета в дайджесте трафика источника), `` не аутентичный '' (т. е. соответствующий дайджест пакета не найден) или `` неизвестно '' (т. е. источник AS не обеспечивает аутентификацию пакета или срок действия пакета истек из дайджеста трафика источника).Сама услуга может быть защищена от манипуляций с использованием техник, аналогичных тем, которые используются в DNSSEC [2].

5 Заключение и дальнейшая работа

В этой статье мы представили PGPA, простой сервис, который позволяет Интернет-провайдер, чтобы определить, отправил ли один из его клиентов данный пакет в какой-то момент в прошлом. PGPA позволяет изменить способ, которым используются исходные IP-адреса: сегодня они являются ненадежным источником информация, которая может быть сфальсифицирована злоумышленниками и может вызвать подозрения на невиновных пользователей; с PGPA адреса источника могут стать ключевыми элемент судебно-медицинской экспертизы, позволяющий надежно подтвердить источник трафика, и позволяя жертвам ложных обвинений доказать их невиновность.PGPA проста в реализации, работает частично развертываний и имеет вероятный путь развертывания. Мы также показали несколько приложений, которые могут извлечь выгоду из использования PGPA. Мы планирует создать прототип монитора трафика, изменив беспроводную точка доступа, а также для реализации службы аутентификации пакетов.

Однако PGPA - это только первый шаг к большей ответственности за Интернет. Многие проблемы не могут быть решены с помощью только PGPA. Например, рассмотрим ситуацию, когда ссылка для доступа пользователя используется совместно, возможно без его ведома или согласия (возможно, через открытый беспроводной точка доступа).Если кто-то, кто делится ссылкой для доступа пользователя плохо себя ведет, пользователь не может доказать свою невиновность с помощью PGPA. Похожий возникает ситуация, когда машина пользователя отправляет незаконный трафик без знание пользователя, например, если машина была заражена вредоносное ПО. Мы оставляем решения для них на будущее.

Список литературы

[1] Д. Г. Андерсен, Х. Балакришнан, Н. Фимстер, Т. Копонен, Д. Мун и С. Шенкер. Подотчетный Интернет-протокол (AIP). В материалах SIGCOMM, август 2008 г.

[2] Д. Э. Истлейк. RFC 2535: Расширения безопасности системы доменных имен. https://www.faqs.org/rfcs/rfc2535.html, март 1999 г.

[3] Дж. Грей. Экономика распределенных вычислений. Технический отчет MSR-TR-2003-24, Microsoft Research, март 2003 г.

[4] С. Гуха, П. Фрэнсис, Н. Тафт. ShutUp: полное сдерживание нежелательного трафика. Технический отчет https://hdl.handle.net/1813/11101, июль 2008 г.

[5] Heise.de. IP-Verwechslung führt zu falschem Kinderporno-Verdacht.https://www.heise.de/newsticker/meldung/105094, 2008 г.

[6] Н. Лаутарис, П. Родригес и Л. Масули. ECHOS: периферийная емкость, на которой размещаются оверлеи наноцентров обработки данных. SIGCOMM Comput. Commun. Rev., 38 (1): 51-54, 2008.

[7] М. Пиатек, Т. Коно и А. Кришнамурти. Проблемы и направления для мониторинга сетей обмена файлами P2P. На 3-м семинаре USENIX по актуальным вопросам безопасности (HotSec '08), июль 2008 г.

[8] А. Рамачандран, Н. Фимстер. Понимание поведения спамеров на сетевом уровне.В материалах SIGCOMM'06, сентябрь 2006 г.

[9] С. Сэвидж, Д. Ветералл, А. Карлин и Т. Андерсон. Практическая сетевая поддержка для отслеживания IP. В материалах SIGCOMM'00, август 2000 г.

[10] А. К. Снерен, К. Партридж, Л. А. Санчес, К. Э. Джонс, Ф. Чакунтио, Б. Шварц, С. Т. Кент и У. Т. Страйер. Однопакетная IP-трассировка. IEEE / ACM Trans. Netw., 10 (6): 721-734, 2002.

PostgreSQL: Документация: 10: 20.3. Методы аутентификации

20.3. Методы аутентификации

В следующих подразделах более подробно описаны методы аутентификации.

20.3.1. Доверительная аутентификация

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

trust аутентификация подходит и очень удобна для локальных подключений на однопользовательской рабочей станции. Обычно это , а не , само по себе на многопользовательской машине. Однако вы можете использовать trust даже на многопользовательской машине, если вы ограничите доступ к файлу сокета домена Unix сервера с помощью разрешений файловой системы.Для этого установите параметры конфигурации unix_socket_permissions (и, возможно, unix_socket_group ), как описано в Разделе 19.3. Или вы можете установить параметр конфигурации unix_socket_directories , чтобы поместить файл сокета в каталог с соответствующими ограничениями.

Установка разрешений файловой системы помогает только для соединений Unix-сокетов. Локальные соединения TCP / IP не ограничиваются разрешениями файловой системы. Поэтому, если вы хотите использовать разрешения файловой системы для локальной безопасности, удалите хост ... 127.0.0.1 ... из pg_hba.conf , или измените его на метод аутентификации без доверия trust .

trust Аутентификация подходит только для соединений TCP / IP, если вы доверяете каждому пользователю на каждом компьютере, которому разрешено подключаться к серверу строками pg_hba.conf , которые указывают trust . Редко бывает разумно использовать trust для любых соединений TCP / IP, кроме соединений с localhost (127.0.0.1).

20.3.2. Парольная аутентификация

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

scram-sha-256

Метод scram-sha-256 выполняет аутентификацию SCRAM-SHA-256, как описано в RFC 7677. Это схема запрос-ответ, которая предотвращает перехват пароля в ненадежных соединениях и поддерживает хранение паролей на сервере в криптографически хешированной форме. это считается безопасным.

Это наиболее безопасный из доступных в настоящее время методов, но он не поддерживается более старыми клиентскими библиотеками.

мкр5

Метод md5 использует настраиваемый менее безопасный механизм запрос-ответ. Он предотвращает перехват пароля и позволяет избежать хранения паролей на сервере в виде обычного текста, но не обеспечивает защиты, если злоумышленнику удается украсть хэш пароля с сервера. Кроме того, алгоритм хеширования MD5 в настоящее время больше не считается защищенным от определенных атак.

Метод md5 нельзя использовать с функцией db_user_namespace.

Чтобы упростить переход от метода md5 к более новому методу SCRAM, если md5 указан как метод в pg_hba.conf , но пароль пользователя на сервере зашифрован для SCRAM (см. Ниже), тогда SCRAM- Вместо этого автоматически будет выбрана основанная на аутентификации.

пароль

Метод пароль отправляет пароль в виде открытого текста и поэтому уязвим для атак «сниффинга».По возможности всегда следует избегать этого. Если соединение защищено шифрованием SSL, то можно безопасно использовать пароль . (Хотя проверка подлинности сертификата SSL может быть лучшим выбором, если он зависит от использования SSL).

Пароли базы данных PostgreSQL отличаются от паролей пользователей операционной системы. Пароль для каждого пользователя базы данных хранится в системном каталоге pg_authid . Паролями можно управлять с помощью команд SQL CREATE USER и ALTER ROLE, например.g., СОЗДАТЬ ПОЛЬЗОВАТЕЛЬСКИЙ foo С ПАРОЛЕМ 'secret' или командой psql \ password . Если для пользователя не установлен пароль, сохраненный пароль будет нулевым, и аутентификация по паролю всегда будет неуспешной для этого пользователя.

Доступность различных методов аутентификации на основе пароля зависит от того, как пароль пользователя на сервере зашифрован (или, точнее, хеширован). Это контролируется параметром конфигурации password_encryption во время установки пароля.Если пароль был зашифрован с использованием настройки scram-sha-256 , то его можно использовать для методов аутентификации scram-sha-256 и password (но в последнем случае передача пароля будет осуществляться в виде обычного текста) . Спецификация метода аутентификации md5 автоматически переключится на использование метода scram-sha-256 в этом случае, как описано выше, поэтому он также будет работать. Если пароль был зашифрован с использованием параметра md5 , то его можно использовать только для спецификаций метода аутентификации md5 и password (опять же, с паролем, передаваемым в виде обычного текста в последнем случае).(Предыдущие выпуски PostgreSQL поддерживали сохранение пароля на сервере в виде обычного текста. Это больше невозможно.) Чтобы проверить сохраненные в настоящее время хэши паролей, см. Системный каталог pg_authid .

Чтобы обновить существующую установку с md5 до scram-sha-256 , убедившись, что все используемые клиентские библиотеки достаточно новые для поддержки SCRAM, установите password_encryption = 'scram-sha-256' в postgresql .conf , заставьте всех пользователей устанавливать новые пароли и измените спецификации метода аутентификации в pg_hba.conf с по scram-sha-256 .

20.3.3. GSSAPI Аутентификация

GSSAPI - это стандартный протокол для безопасной аутентификации, определенный в RFC 2743. PostgreSQL поддерживает GSSAPI с аутентификацией Kerberos в соответствии с RFC 1964. GSSAPI обеспечивает автоматическую аутентификацию (единый вход) для систем, которые его поддерживают. Сама аутентификация является безопасной, но данные, отправляемые через соединение с базой данных, будут отправляться в незашифрованном виде, если не используется SSL.

При сборке PostgreSQL должна быть включена поддержка

GSSAPI; см. главу 16 для получения дополнительной информации.

Когда GSSAPI использует Kerberos, он использует стандартный принципал в формате имя_службы / имя хоста @ область . Сервер PostgreSQL примет любого принципала, включенного в ключевую таблицу, используемую сервером, но необходимо позаботиться о том, чтобы указать правильные данные принципала при установлении соединения от клиента с использованием параметра соединения krbsrvname .(См. Также Раздел 33.1.2.) Установку по умолчанию можно изменить с postgres по умолчанию во время сборки, используя ./configure --with-krb-srvnam = независимо от . В большинстве сред этот параметр никогда не нужно изменять. Для некоторых реализаций Kerberos может потребоваться другое имя службы, например Microsoft Active Directory, которое требует, чтобы имя службы было в верхнем регистре ( POSTGRES ).

имя хоста - полное имя хоста серверного компьютера.Область субъекта-службы - это предпочтительная область серверного компьютера.

Принципалы клиентов могут быть сопоставлены с разными именами пользователей базы данных PostgreSQL с помощью pg_ident.conf . Например, pgusername @ realm можно сопоставить только с pgusername . В качестве альтернативы вы можете использовать полное имя пользователя @ realm в качестве имени роли в PostgreSQL без какого-либо сопоставления.

PostgreSQL также поддерживает параметр для удаления области из принципала.Этот метод поддерживается для обратной совместимости и настоятельно не рекомендуется, поскольку в этом случае невозможно различить разных пользователей с одним и тем же именем, но из разных областей. Чтобы включить это, установите для include_realm значение 0. Для простых установок с одной областью выполнение этого в сочетании с установкой параметра krb_realm (который проверяет, что область главного пользователя точно совпадает с тем, что указано в параметре krb_realm ) по-прежнему безопасно; но это менее эффективный подход по сравнению с указанием явного отображения в pg_ident.conf .

Убедитесь, что файл keytab вашего сервера доступен для чтения (и желательно только для чтения, но не для записи) учетной записью сервера PostgreSQL. (См. Также Раздел 18.1.) Местоположение ключевого файла определяется параметром конфигурации krb_server_keyfile. По умолчанию /usr/local/pgsql/etc/krb5.keytab (или любой другой каталог, указанный как sysconfdir во время сборки). По соображениям безопасности рекомендуется использовать отдельную вкладку ключей только для сервера PostgreSQL, а не открывать разрешения для файла системной таблицы ключей.

Файл keytab создается программой Kerberos; подробности см. в документации Kerberos. Следующий пример предназначен для MIT-совместимых реализаций Kerberos 5:

  kadmin%    ank -randkey postgres / server.my.domain.org  
  kadmin%    ktadd -k krb5.keytab postgres / server.my.domain.org   

При подключении к базе данных убедитесь, что у вас есть билет для принципала, соответствующий запрошенному имени пользователя базы данных.Например, для имени пользователя базы данных fred сможет подключиться принципал [email protected] . Чтобы также разрешить принципалу fred/[email protected] , используйте карту имен пользователей, как описано в Разделе 20.2.

Для GSSAPI поддерживаются следующие параметры конфигурации:

include_realm

Если установлено значение 0, имя области от аутентифицированного участника-пользователя удаляется перед передачей через отображение имени пользователя (раздел 20.2). Это не рекомендуется и в первую очередь доступно для обратной совместимости, так как это небезопасно в средах с несколькими областями, если также не используется krb_realm . Рекомендуется оставить include_realm установленным по умолчанию (1) и предоставить явное отображение в pg_ident.conf для преобразования основных имен в имена пользователей PostgreSQL.

карта

Позволяет отображать имена пользователей системы и базы данных. См. Раздел 20.2 для подробностей. Для принципала GSSAPI / Kerberos, такого как [email protected] (или, реже, username/[email protected] ), имя пользователя, используемое для сопоставления, - [email protected] (или username/[email protected] соответственно), если для include_realm не было установлено значение 0, и в этом случае username (или username / hostbased ) - это то, что отображается как системное имя пользователя при сопоставлении.

krb_realm

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

20.3.4. SSPI Аутентификация

SSPI - это технология Windows для безопасной аутентификации с единым входом. PostgreSQL будет использовать SSPI в режиме согласования , который будет использовать Kerberos, когда это возможно, и автоматически вернуться к NTLM в других случаях. Аутентификация SSPI работает только тогда, когда и сервер, и клиент работают под Windows или, на платформах, отличных от Windows, когда доступен GSSAPI.

При использовании аутентификации Kerberos SSPI работает так же, как GSSAPI; подробности см. в Разделе 20.3.3.

Для SSPI поддерживаются следующие параметры конфигурации:

include_realm

Если установлено значение 0, имя области от аутентифицированного пользователя-участника удаляется перед передачей через отображение имени пользователя (раздел 20.2). Это не рекомендуется и в первую очередь доступно для обратной совместимости, так как это небезопасно в средах с несколькими областями, если также не используется krb_realm .Рекомендуется оставить include_realm установленным по умолчанию (1) и предоставить явное отображение в pg_ident.conf для преобразования основных имен в имена пользователей PostgreSQL.

compat_realm

Если установлено значение 1, SAM-совместимое имя домена (также известное как имя NetBIOS) используется для параметра include_realm . Это значение по умолчанию. Если установлено значение 0, используется истинное имя области из основного имени пользователя Kerberos.

Не отключайте эту опцию, если ваш сервер не работает под учетной записью домена (включая учетные записи виртуальных служб в системе-члене домена) и все клиенты, аутентифицируемые через SSPI, также не используют доменные учетные записи, иначе аутентификация не удастся.

upn_username

Если эта опция включена вместе с compat_realm , имя пользователя из Kerberos UPN используется для аутентификации. Если он отключен (по умолчанию), используется SAM-совместимое имя пользователя. По умолчанию эти два имени идентичны для новых учетных записей пользователей.

Обратите внимание, что libpq использует SAM-совместимое имя, если не указано явное имя пользователя. Если вы используете libpq или драйвер на его основе, вам следует оставить этот параметр отключенным или явно указать имя пользователя в строке подключения.

карта

Позволяет отображать имена пользователей системы и базы данных. За подробностями обратитесь к Разделу 20.2. Для участника SSPI / Kerberos, такого как [email protected] (или, реже, username/[email protected] ), имя пользователя, используемое для сопоставления, - [email protected] (или username/[email protected] соответственно), если для include_realm не было установлено значение 0, и в этом случае username (или username / hostbased ) - это то, что отображается как системное имя пользователя при сопоставлении.

krb_realm

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

20.3.5. Идентификационная аутентификация

Метод аутентификации с помощью идентификатора работает путем получения имени пользователя операционной системы клиента с сервера идентификатора и использования его в качестве разрешенного имени пользователя базы данных (с необязательным отображением имени пользователя).Это поддерживается только для соединений TCP / IP.

Примечание

Если идентификатор указан для локального (не TCP / IP) соединения, вместо него будет использоваться одноранговая аутентификация (см. Раздел 20.3.6).

Следующие параметры конфигурации поддерживаются для идентификатора:

карта

Позволяет отображать имена пользователей системы и базы данных. За подробностями обратитесь к Разделу 20.2.

«Протокол идентификации» описан в RFC 1413.Практически каждая Unix-подобная операционная система поставляется с сервером идентификации, который по умолчанию прослушивает порт 113 TCP. Основная функциональность сервера идентификации заключается в том, чтобы отвечать на такие вопросы, как «Какой пользователь инициировал соединение, которое выходит из вашего порта X и подключается к моему порту Y ?». Поскольку PostgreSQL знает как X , так и Y , когда установлено физическое соединение, он может опросить сервер identity на хосте подключающегося клиента и теоретически определить пользователя операционной системы для любого данного соединения.

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

Протокол идентификации не предназначен для использования в качестве протокола авторизации или управления доступом.

--RFC 1413

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

20.3.6. Одноранговая аутентификация

Метод одноранговой аутентификации работает путем получения от ядра имени пользователя операционной системы клиента и использования его в качестве разрешенного имени пользователя базы данных (с необязательным отображением имени пользователя). Этот метод поддерживается только для локальных подключений.

Для однорангового узла поддерживаются следующие параметры конфигурации:

карта

Позволяет отображать имена пользователей системы и базы данных.За подробностями обратитесь к Разделу 20.2.

Одноранговая аутентификация доступна только в операционных системах, предоставляющих функцию getpeereid () , параметр сокета SO_PEERCRED или аналогичные механизмы. В настоящее время это Linux, большинство разновидностей BSD, включая macOS и Solaris.

20.3.7. Аутентификация LDAP

Этот метод аутентификации работает аналогично паролю , за исключением того, что он использует LDAP в качестве метода проверки пароля.LDAP используется только для проверки пар имя пользователя / пароль. Поэтому пользователь должен уже существовать в базе данных, прежде чем LDAP можно будет использовать для аутентификации.

Аутентификация LDAP может работать в двух режимах. В первом режиме, который мы будем называть режимом простого связывания, сервер будет связываться с отличительным именем, построенным как префикс имя пользователя суффикс . Обычно префикс , параметр используется для указания cn = или DOMAIN \ в среде Active Directory. суффикс используется для указания оставшейся части DN в среде, отличной от Active Directory.

Во втором режиме, который мы назовем режимом поиска + привязки, сервер сначала связывается с каталогом LDAP с фиксированным именем пользователя и паролем, указанным с помощью ldapbinddn и ldapbindpasswd , и выполняет поиск для пользователя, пытающегося войти в базу данных. Если пользователь и пароль не настроены, будет предпринята попытка анонимной привязки к каталогу.Поиск будет выполняться по поддереву по адресу ldapbasedn и будет пытаться выполнить точное совпадение атрибута, указанного в ldapsearchattribute . После того, как пользователь был найден в этом поиске, сервер отключается и повторно связывается с каталогом как этот пользователь, используя пароль, указанный клиентом, для проверки правильности входа в систему. Этот режим аналогичен тому, который используется схемами аутентификации LDAP в другом программном обеспечении, таком как Apache mod_authnz_ldap и pam_ldap .Этот метод обеспечивает значительно большую гибкость в том, где расположены объекты пользователя в каталоге, но потребует создания двух отдельных подключений к серверу LDAP.

В обоих режимах используются следующие параметры конфигурации:

ldapserver

Имена или IP-адреса серверов LDAP для подключения. Можно указать несколько серверов, разделенных пробелами.

ldapport

Номер порта на сервере LDAP для подключения.Если порт не указан, будет использоваться настройка порта по умолчанию библиотеки LDAP.

ldaptls

Установите значение 1, чтобы соединение между PostgreSQL и сервером LDAP использовало шифрование TLS. Обратите внимание, что это только шифрует трафик к серверу LDAP - соединение с клиентом будет по-прежнему незашифрованным, если не используется SSL.

Следующие параметры используются только в режиме простого связывания:

ldapprefix

Строка, добавляемая к имени пользователя при формировании DN для привязки при выполнении простой аутентификации привязки.

ldapsuffix

Строка, добавляемая к имени пользователя при формировании DN для привязки, когда выполняется простая проверка подлинности привязки.

Следующие параметры используются только в режиме поиска + привязки:

ldapbasedn

Root DN для начала поиска пользователя при выполнении аутентификации search + bind.

ldapbinddn

DN пользователя, которого нужно привязать к каталогу для выполнения поиска при выполнении аутентификации search + bind.

ldapbindpasswd

Пароль для привязки пользователя к каталогу для выполнения поиска при выполнении аутентификации search + bind.

ldapsearchattribute

Атрибут для сопоставления с именем пользователя в поиске при выполнении аутентификации search + bind. Если атрибут не указан, будет использован атрибут uid .

ldapurl

URL-адрес LDAP RFC 4516.Это альтернативный способ записать некоторые другие параметры LDAP в более компактной и стандартной форме. Формат

 ldap: //   хост   [:   порт  ] /   basedn   [? [  attribute  ] [? [  scope  ]]] 

область должна быть одной из base , one , sub , обычно последней. Используется только один атрибут, а некоторые другие компоненты стандартных URL-адресов LDAP, такие как фильтры и расширения, не поддерживаются.

Для неанонимных привязок необходимо указать ldapbinddn и ldapbindpasswd как отдельные параметры.

Чтобы использовать зашифрованные соединения LDAP, необходимо использовать параметр ldaptls в дополнение к ldapurl . Схема URL-адреса ldaps (прямое соединение SSL) не поддерживается.

URL-адреса LDAP в настоящее время поддерживаются только OpenLDAP, но не Windows.

Ошибочно смешивать параметры конфигурации для простого связывания с параметрами поиска + связывания.

Вот пример конфигурации LDAP с простым связыванием:

 хост ... ldap ldapserver = ldap.example.net ldapprefix = "cn =" ldapsuffix = ", dc = example, dc = net" 

Когда запрашивается соединение с сервером базы данных в качестве пользователя базы данных someuser , PostgreSQL попытается подключиться к серверу LDAP, используя DN cn = someuser, dc = example, dc = net и пароль, предоставленный клиентом. Если это соединение установлено успешно, доступ к базе данных предоставляется.

Вот пример конфигурации поиска + привязки:

 хост... ldap ldapserver = ldap.example.net ldapbasedn = "dc = example, dc = net" ldapsearchattribute = uid 

Когда запрашивается соединение с сервером базы данных в качестве пользователя базы данных someuser , PostgreSQL попытается анонимно выполнить привязку (поскольку ldapbinddn не был указан) с сервером LDAP, выполните поиск (uid = someuser) под указанное базовое DN. Если запись найдена, она попытается выполнить привязку, используя найденную информацию и пароль, предоставленный клиентом.Если это второе соединение будет успешным, доступ к базе данных будет предоставлен.

Вот та же конфигурация поиска + привязки, записанная как URL:

 хост ... ldap ldapurl = "ldap: //ldap.example.net/dc=example,dc=net? Uid? Sub" 

Некоторое другое программное обеспечение, поддерживающее аутентификацию по LDAP, использует тот же формат URL, что упрощает совместное использование конфигурации.

Подсказка

Поскольку LDAP часто использует запятые и пробелы для разделения различных частей DN, часто бывает необходимо использовать значения параметров в двойных кавычках при настройке опций LDAP, как показано в примерах.

20.3.8. Аутентификация RADIUS

Этот метод аутентификации работает аналогично паролю , за исключением того, что он использует RADIUS в качестве метода проверки пароля. RADIUS используется только для проверки пар имя пользователя / пароль. Поэтому пользователь должен уже существовать в базе данных, прежде чем RADIUS можно будет использовать для аутентификации.

При использовании аутентификации RADIUS сообщение запроса доступа будет отправлено на настроенный сервер RADIUS. Этот запрос будет иметь тип Authenticate Only и включать параметры для имени пользователя , пароля (зашифрованный) и идентификатора NAS .Запрос будет зашифрован с использованием секрета, совместно используемого с сервером. Сервер RADIUS ответит на этот запрос либо Access Accept , либо Access Reject . Нет поддержки учета RADIUS.

Можно указать несколько серверов RADIUS, и в этом случае они будут проверяться последовательно. Если от сервера получен отрицательный ответ, аутентификация не удастся. Если ответа не будет, будет произведена попытка следующего сервера в списке. Чтобы указать несколько серверов, разделите имена серверов запятыми и заключите список в двойные кавычки.Если указано несколько серверов, другие параметры RADIUS также могут быть заданы в виде списков, разделенных запятыми, чтобы предоставить индивидуальные значения для каждого сервера. Их также можно указать как одно значение, и в этом случае это значение будет применяться ко всем серверам.

Для RADIUS поддерживаются следующие параметры конфигурации:

radiusservers

DNS-имена или IP-адреса серверов RADIUS для подключения. Этот параметр обязателен.

radiussecrets

Общие секреты, используемые при безопасном разговоре с серверами RADIUS.Это должно иметь точно такое же значение на серверах PostgreSQL и RADIUS. Рекомендуется, чтобы это была строка длиной не менее 16 символов. Этот параметр обязателен.

Примечание

Используемый вектор шифрования будет криптостойким только в том случае, если PostgreSQL построен с поддержкой OpenSSL. В других случаях передачу на сервер RADIUS следует рассматривать только как запутанную, а не защищенную, и при необходимости следует применять внешние меры безопасности.

radiusports

Номера портов для подключения на серверах RADIUS.Если порт не указан, будет использоваться порт RADIUS по умолчанию ( 1812 ).

радиусидентификаторы

Строки, которые будут использоваться в качестве идентификатора NAS в запросах RADIUS. Этот параметр можно использовать, например, для определения того, к какому кластеру базы данных пытается подключиться пользователь, что может быть полезно для сопоставления политик на сервере RADIUS. Если идентификатор не указан, будет использоваться значение по умолчанию postgresql .

Если необходимо иметь запятую или пробел в значении параметра RADIUS, это можно сделать, заключив значение в двойные кавычки, но это утомительно, потому что теперь требуются два уровня двойных кавычек.Пример помещения пробелов в секретные строки RADIUS:

 хост ... radius radiusservers = "server1, server2" radiussecrets = "" "секретный один" "," "секретный два" "" 

20.3.9. Проверка подлинности сертификата

Этот метод аутентификации использует сертификаты клиента SSL для аутентификации. Поэтому он доступен только для SSL-соединений. При использовании этого метода аутентификации сервер потребует, чтобы клиент предоставил действительный доверенный сертификат.Запрос пароля не будет отправлен клиенту. Атрибут cn (общее имя) сертификата будет сравниваться с запрошенным именем пользователя базы данных, и, если они совпадают, будет разрешен вход в систему. Можно использовать сопоставление имен пользователей, чтобы разрешить cn отличаться от имени пользователя базы данных.

Для проверки подлинности сертификата SSL поддерживаются следующие параметры конфигурации:

карта

Позволяет отображать имена пользователей системы и базы данных.За подробностями обратитесь к Разделу 20.2.

В записи pg_hba.conf , определяющей аутентификацию сертификата, предполагается, что опция аутентификации clientcert равна 1 , и ее нельзя отключить, поскольку для этого метода необходим сертификат клиента. Метод cert добавляет к базовому тесту достоверности сертификата clientcert проверку того, что атрибут cn соответствует имени пользователя базы данных.

20.3.10. PAM аутентификация

Этот метод аутентификации работает аналогично паролю , за исключением того, что он использует PAM (подключаемые модули аутентификации) в качестве механизма аутентификации. Имя службы PAM по умолчанию - postgresql . PAM используется только для проверки пар имя пользователя / пароль и, необязательно, имени подключенного удаленного хоста или IP-адреса. Поэтому пользователь должен уже существовать в базе данных, прежде чем PAM можно будет использовать для аутентификации. Для получения дополнительной информации о PAM, пожалуйста, прочтите страницу Linux-PAM.

Для PAM поддерживаются следующие параметры конфигурации:

памсервис

Имя службы PAM.

pam_use_hostname

Определяет, предоставляется ли удаленный IP-адрес или имя хоста модулям PAM через элемент PAM_RHOST . По умолчанию используется IP-адрес. Установите для этого параметра значение 1, чтобы вместо этого использовать разрешенное имя хоста. Разрешение имени хоста может привести к задержкам входа в систему.(Большинство конфигураций PAM не используют эту информацию, поэтому этот параметр необходимо учитывать только в том случае, если конфигурация PAM была специально создана для его использования.)

Примечание

Если PAM настроен на чтение / etc / shadow , аутентификация не удастся, потому что сервер PostgreSQL запущен пользователем без полномочий root. Однако это не проблема, если PAM настроен на использование LDAP или других методов аутентификации.

20.3.11. Аутентификация BSD

Этот метод аутентификации работает аналогично паролю , за исключением того, что он использует аутентификацию BSD для проверки пароля.Аутентификация BSD используется только для проверки пар имя пользователя / пароль. Поэтому роль пользователя должна уже существовать в базе данных, прежде чем аутентификация BSD может быть использована для аутентификации. Фреймворк BSD Authentication в настоящее время доступен только в OpenBSD.

Аутентификация

BSD в PostgreSQL использует тип входа auth-postgresql и аутентифицируется с помощью класса входа postgresql , если он определен в login.conf . По умолчанию этот класс входа в систему не существует, и PostgreSQL будет использовать класс входа по умолчанию.

Примечание

Чтобы использовать аутентификацию BSD, учетную запись пользователя PostgreSQL (то есть пользователя операционной системы, запускающего сервер) необходимо сначала добавить в группу auth . Группа auth существует по умолчанию в системах OpenBSD.

5 Целостность и подлинность записей | Создание электронного архива документации в Национальном управлении архивов и документации: рекомендации для долгосрочной стратегии

Гарантии для метаданных

Некоторые метаданные являются важным дополнением к записи и должны быть соответственно защищены.Например, дата создания записи может не быть частью записи, а вместо этого записываться как метаданные. Эти метаданные должны быть защищены цифровыми гарантиями, как и все остальные записи.

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

МОДЕЛИРОВАНИЕ УГРОЗ И УПРАВЛЕНИЕ УГРОЗАМИ

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

После разработки модели угроз, разработки способов противодействия ожидаемым угрозам и построения системы следует затем наблюдать за системой, чтобы увидеть, какие виды нарушений целостности, аутентичности и безопасности возникают, несмотря на тщательно разработанные планы.Затем этот анализ отказов используется для корректировки модели угроз, разработки дополнительных или более эффективных процедур противодействия угрозам и для обновления системы. Процесс повторяется в течение всего срока службы системы. Все системы, которые должны обеспечивать отказоустойчивость, целостность, безопасность или безопасность жизни, требуют такого рода непрерывных итераций на протяжении всего их жизненного цикла. Модное слово - «проектирование для итераций», и такой стиль проектирования системы делает механизм обратной связи важным компонентом проектирования системы.

ЭВОЛЮЦИЯ ОБЕСПЕЧЕНИЯ УЧЕТА

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

При нынешних методах методы цепочки поставок и обеспечения уверенности настолько сильны, насколько сильны их самые слабые звенья. Архив, который превосходно гарантирует целостность своих записей, бесполезен, если агентства, отправляющие записи в архив, небрежно относятся к любому аспекту управления записями, находящимися на их хранении. Чтобы гарантировать, что ERA через десятилетия будет цениться как источник достоверных государственных документов, вся цепочка хранения документации должна использовать надежные гарантии.

Продвижение цифровой гарантии в федеральном правительстве

Приведенные выше аргументы явно призывают к применению цифровых гарантий к записям на протяжении всей их жизни, а не только с момента их приема NARA. Однако цифровой

Конфигурация межсетевого экрана | Служба поддержки нотариуса

Конфигурация межсетевого экрана

Какая информация передается, как и почему? - Соображения безопасности - Правила конфигурации брандмауэра

Сводка
Для активации, использования и проверки цифровой подписи Notarius необходимо включить четыре исходящих потока связи на серверы Notarius.Эти потоки всегда инициируются с данной рабочей станции и используют стандартные протоколы. Никакая информация, относящаяся к вашим электронным документам, не передается Нотариусу или третьим лицам.

Notarius - единственный поставщик инфраструктуры открытого ключа, имеющий сертификат ISO 27001 в Северной Америке (Управление информационной безопасностью). Более того, его инфраструктура подлежит строгому контролю безопасности и периодическому тестированию на уязвимость. Несколько крупных компаний, работающих в инженерном, транспортном, аэрокосмическом, гидроэнергетическом и горнодобывающем секторах, разрешают исходящие потоки связи на серверы Notarius.

Почему Нотариус?

CertifiO, надежная цифровая подпись от Notarius, позволяет пользователям подписывать электронный документ с той же юридической силой, что и собственноручная подпись на печатном документе. Он гарантирует происхождение, целостность и подлинность документа. CertifiO for Professionals - это единственная цифровая подпись, признанная 25 профессиональными ассоциациями Канады.

Какая информация передается, как и почему?

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

Использует ли ваша организация прокси? LDAP (tcp 389) и CMP (tcp 829) не поддерживают прокси.
У нас есть решение, использующее только http и https.

Сервис Описание Порт
Лицензирование ConsignO Зашифрованный обмен данными для управления правами пользователя ConsignO. Сюда входит файл лицензии и публичное отличительное имя (DN) подписавшего.
Требуется для использования ConsignO.
TCP 443 (https)
Создание цифровой подписи Зашифрованный обмен данными для активации, обновления или восстановления сертификата цифровой подписи. Включает всю необходимую информацию для создания доверенной пары открытого / закрытого ключей на компьютере пользователя. Использует CMP (протокол управления сертификатами). Ссылка: RFC 6712
Требуется для получения сертификата цифровой подписи.
TCP 443 (https) TCP 829
(pkix-3-ca-ra)
Авторитет отметок времени Добавить сертифицированный токен отметки времени при подписи.Использует TSP (протокол отметок времени). Ссылка: RFC 3161
Требуется для обеспечения долгосрочной надежности документа.
TCP 80 (HTTP)
Ответчик OCSP Добавьте доказательство действительности цифровой подписи и проверьте подлинность документа. Сообщение включает публичное отличительное имя (DN) подписавшего. Использует OCSP (протокол статуса онлайн-сертификата). Ссылка: RFC 6960
Требуется для обеспечения подлинности и долговременной надежности документа.
TCP 80 (HTTP)
Список отозванных сертификатов (CRL) Добавьте доказательство действительности цифровой подписи и проверьте подлинность документа. Использует LDAP (облегченный протокол доступа к каталогам). Ссылка: RFC 2251
Требуется для обеспечения подлинности и долговременной надежности документа.
tcp 80
(ldap поверх http)
или
tcp 389 (ldap) 1
Регистрация, активация и управление цифровой подписью Зашифрованный обмен данными между браузером и порталом управления для регистрации, активации, управления и выставления счетов за цифровые подписи.
Требуется для получения цифровой подписи.
TCP 443 (https)
Шаблоны скачать Незашифрованный обмен данными с шаблонами PDF и XML ConsignO Desktop. TCP 80 (HTTP)
Уведомления Зашифрованная связь для получения уведомлений об обновлениях и уведомлений «Что нового». TCP 443 (https)
Менеджер по сертификации Легкое настольное приложение, избавляющее от необходимости устанавливать JAVA для доступа к вашей учетной записи на портале Notarius, для активации или восстановления вашей цифровой подписи CertifiO и для входа в приложение, такое как ConsignO Cloud, с ее помощью. TCP 443, 24250 (https)
CertifiO Manager - Serveur Edition Server Edition позволяет нескольким пользователям использовать CertifiO Manager на сервере или в виртуальной среде. TCP 443, 24251-24270 (https)

1 Организации, которые предпочитают блокировать порт TCP 389 (ldap), могут сделать это, если порт tcp 80 (http) может передавать трафик с наших серверов. См. Подробности на странице конфигурации прокси.

Какие соображения безопасности связаны с этими потоками?

Эти потоки всегда исходящие: они инициируются с клиентской рабочей станции на серверы Notarius с использованием стандартных протоколов. Никакая информация, относящаяся к вашим электронным документам, не передается Нотариусу или третьим лицам. Notarius - единственный поставщик инфраструктуры открытого ключа, имеющий сертификат ISO 27001 в Северной Америке (Управление информационной безопасностью). Более того, его инфраструктура подлежит строгому контролю безопасности и периодическому тестированию на уязвимость.

Кому нужны эти потоки или кому они доверяют?

Помимо нотариуса, программное обеспечение центра сертификации Entrust и связанные с ним технологии используют Организация Объединенных Наций, правительство Канады и правительства нескольких канадских провинций и штатов США; все требуют, чтобы поток связи с их серверами был авторизован. Эти протоколы связи регулируются строгими стандартами, установленными IETF, ISO и NIST.

Некоторые клиенты Notarius также оценили эти соображения.Крупные компании, работающие в инженерном, транспортном, аэрокосмическом, гидроэнергетическом и горнодобывающем секторах, разрешают исходящие потоки связи на серверы Notarius.

Каковы правила брандмауэра?

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

Диапазон IP Порт
206,55.89,0 / 27 TCP 80 (HTTP)
TCP 443 (https)
TCP 389 (LDAP) 1
TCP 829 (PKIX-КАРА)
192.252.131.64/28 TCP 80 (http)
TCP 443 (https)
TCP 389 (LDAP) 1
TCP 829 (PKIX-CA-RA)


Для нашего сайта загрузки и веб-сайта требуется конфигурация DNS.

Запись DNS Порт
поддержка.notarius.com TCP 443 (https)
download.notarius.com TCP 80 (HTTP)
TCP 443 (https)

Примечания:

  1. Организации, которые предпочитают блокировать порт TCP 389 (ldap), могут сделать это, если порт tcp 80 (http) может передавать трафик с наших серверов. См. Подробности на странице конфигурации прокси.
  2. Все коммуникации только исходящие ; они инициируются клиентом на наши серверы.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *