Здравствуйте, уважаемые форумчане!

Позвольте задать вопрос, который может показаться немного странным, но смысл однако в нём есть.

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

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

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

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

В этой связи возникает вопрос - а можно ли проделать всё то же самое, но без ssl? Вручную? Есть ли пары NET-JavaScript или php-JavaScript функций, одна из которых на сервере "изобретает" открытый и закрытый ключи для шифрования, а другая на клиенте шифрует пользовательский трафик?

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

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

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

Искренне ваш
aLEXperimentator

Верстка-то тут при чем? Раздел выбирайте в следующий раз внимательнее.

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

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

такое бывает? Менять на unix-сервер. nginx и апач оба прекрасно работают с ssl

Собственный самоподписанный сертификат - то что надо? 

Хостинг на windows стоит, обычно, дороже хостинга на unix в 2-3 раза. Может прощу сменить дорогой хостинг на более удобный и дешевый? 

Спасибо за ответы, уважаемые Aliance и ksnk!

Да, действительно ошибся с темой, прошу прощения. Форум большой, иногда трудно понять наилучшее расположение для темы.

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

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

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

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

 Такой вариант скрипта я себе написал, никаких https, ssl,  приобретений у сертифицирующих центров, потому что и у меня банально нет денег платить за такие опыты, а поэксперементировать с сайтом тоже хочу.
 Пары NET-JavaScript или php-JavaScript функций, одна из которых на сервере "изобретает" открытый и закрытый ключи для шифрования, а другая на клиенте шифрует пользовательский трафик найти не удалось, пришлось все делать самому.
Времени потратил массу. Результат получил. Цели своей все же не достиг, потому что цель шифрования была не соцсети. Хотя в принципе использование подобной схемы в соцсетях возможно. Где использовать свой скрипт, и нужно ли это вообще, пока не определился. 
 Вы также можете написать себе аналогичный скрипт, при наличии достаточного времени и большого желания/потребности.
 
 

Спасибо за ответ, уважаемый Cisa

Да, по-видимому придётся или делать самому, или, если это очень трудоёмко или приведёт к существенным временнЫм затратам для сервера - придётся искать другие способы.

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

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

Ведь "родные заводские пары функций" по-любому будут работать быстрее моих каких-нибудь document.all в JavaScript или регулярных выражений на PHP. "Заводские родные для процессора" типы int32 или int64 и команды к ним, обрабатывающие сразу 2 или 4 байта будут в любом случае быстрее моей собственной арифметики...

Вот чего не хотелось бы делать. Не хотелось бы писать "кривой велосипед".

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

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

Да ни в жисть!  Не, серьёзно нет. Никаких сторонних браузеров, никаких дополнительных заплаток или сторонних библиотек. Всё стандартное, кроссплатформенное, и средствами, существующими на любом браузере под любой более-менее современной ОС - хоть под Мак, хоть под Win, хоть под Android Mobile.

Хотелось бы сделать именно так... (мечтательный смайлик) 

А от чего обороняемся-то? Если от MITM атаки, то можно ограничить себя одним ajax'ом. 
Загружается минимальная библиотечка. Она получает зашифрованный пакет от сервера, расшифровывает и вставляет в нужное место ДОМ'а. Формы и переходы тоже перехватываются JS, шифруются и дешифруются... Понятно, что все сеошные и поисковые тонкости сразу идут лесом. 

Возможно, какие-то алгоритмы можно подцепить из Cripto-js. Там, вроде, даже и с Open SSL есть примеры.

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

Человек доверяет мне свои учётные данные. Значит на меня ложится ответственность за их сохранение.

Вот для первого раза и нужен асимметричный ключ...

Потом можно обменяться симметричными ключами, потом можно заставить JavaScript (правда не знаю - можно ли - но читал что можно) создать куку со временем жизни до момента закрытия браузера, сгенерировать и положить в эту куку симметричный ключ, отослать его в зашифрованном виде на сервер, потом получать/отправлять страницы в зашифрованном виде - тут Вы конечно же правы. Можно вообще не шифровать исходящий трафик, особенно если речь идёт о публичном ресурсе - ну какая разница - зашифрую я свой пост или нет при отправке? Всё равно Вы его потом прочитаете на форуме! Можно много чего делать, но сам момент авторизации - когда юзер передаёт свои учётные данные - должен быть защищён. Хотя бы один раз, но асимметричное шифрование должно быть использовано. Это потом залогиненному человеку будет открыта сессия, и когда сервер понимает, с кем конкретно он имеет дело - работать становится уже проще. Момент же передачи данных должен, на мой взгляд, быть защищён...


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

Спасибо большое, но если не ошибаюсь - я Crypto-js уже смотрел. Да и чесгря не всегда хочется грузить чужие библиотеки. Ну к примеру возьмите библиотеки MathJax и jsMath для преобразования текста в математические формулы. Библиотека весом несколько (если сейчас правильно навскидку помню) то ли мегабайт, то ли десятков мегабайт, подгружаясь, способна вполне реально "подвесить" даже очень неслабый компьютер на несколько секунд.

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

Добавлено через 12 минут и 46 секунд
В принципе есть серия обходных путей, которые могут решить проблему:

Можно использовать к примеру логинзу - сервис авторизации через соц-сети. То есть если в соседней вкладке браузера человек в данный момент зарегистрирован вКонтакте, на Фейсбуке, Инстаграмме или в "МоёмМире" - то авторизация происходит на основании ответа, возвращаемого социальной сетью. Правда я не знаю - как проверить подлинность ответа от социальной сети - действительно ли это социальная сеть через браузер юзера мне ответила, что данный юзер - это Васильев Василий Васильевич, или это хакер подделал ответ якобы от Фейсбука?

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

Лучше чтобы ресурс имел возможность сам проверить и произвести авторизацию, разве нет?

будет неизвестно как работать - как напишите так и будет работать этот велосипед.

10-20 шутников договорятся друг с другом - ну это организовать еще надо. На то и волки чтобы сторож не дремал, ну Вы что то обязательно придумаете для отражения/смягчения такой атаки.

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

"Заводские родные" были бы в любом случае быстрее, если бы были.

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

умножением, делением и сдвигом - и тем и другим и третьим.
особые облегчающие функции - те что есть в js.

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

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

Возможное применение - новая почта, с исключением ситуации   "человек посередине"
https://ru.wikipedia.org/wiki/%D0%A7%D0%B5%...%B8%D0%BD%D0%B5
Но для этого необходимы какие то минимальные стартовые средства.

Ну вот и я про то же самое. Только писать-то придётся в лоб: Math.pow (число, в какой-то большой степени) . Если есть какие-то "оптимизаторские" способы вычисления ключей - мне-то они неизвестны. Вот и хотелось найти сначала нечто более-менее встроенное...

Да, увы. Увы, если их нет.

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

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

А какой длины ключ вообще считается сейчас достаточным? Вроде как они удлиняются постоянно. Когда-то 256 бит хватало, сейчас вроде уже нужны 1024-битные, если ничего не путаю...

Это да.

Думается что всё-таки да. Посудите сами - Яндекс-почта, Мейл-ру, Фейсбук, бывший Хотмейл ныне Аутлук - они рассчитаны на большое число посетителей, но тем не менее используют шифрование. Используют https.

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

Однако по-любому - спасибо, уважаемые Cisa и ksnk за ответы , разъяснения, наводящие вопросы.
От MITM, "человека посередине", как я понимаю, не спасёт никакое самописное шифрование. Только официально купленный верифицированный ssl. Но с другой стороны если какой бездельник в компании-провайдере вдруг начнёт изучать чьи-то http-запросы - в это ещё поверить может быть можно. Но поверить в то, что на провайдере или дальше по линии кто-то всерьёз начнёт внедряться по принципу Алисы и Боба, и какой-нибудь Евы или Мэлори между ними, да ещё ключи подменять - ну на самом деле маловероятно. Ну не ЦРУ-шная же переписка на самом деле, не дипломатическая же - таким перехватом заниматься...

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

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

Однако на практике попытка применить шифр и метод обмена ключами, приведённый в статье, будет являться клоунадой. Ибо после того как Алиса загадает число 3, и будет держать его на хранении, а Бобу передаст результат 2, хакер-перехватчик начнёт возводить открытое число Y подряд в натуральные степени (то есть умножать на себя же) и проверять остатки от деления на открытое число P. В конце концов не то же самое делала Алиса? Умножала, делила, брала остаток, умножала, делила, брала остаток... И получила число 2, которое и передала по линии связи. Таким образом как только хакер тоже доумножается-доделится до остатка 2 - он фактически нашёл число Алисы. Ему понадобится ровно столько же действий, сколько и ей.

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

Копаем дальше.

Блин, может быть на самом деле не морочить и себе, и людям голову?

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

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

И опять-таки остаётся та же самая проблема хостера. Я планировал честно говоря захостить пробный сайт после его готовности на чём-нибудь вроде народ.ру или его преемнике юкозе (там есть платные php-функции, сайт на IIS - уже будет следующая работа). Но в FAQ-е к примеру того же юкоза нет ни слова о ssl. Некоторых других хостеров мне, к примеру, будет не очень удобно оплачивать.

Эх, проблемы, проблемы... Дождусь работоспособности StartSSL - поделюсь инфой дальше 

Ага 



Хочешь ssl? Колись! Адрес давай! Домашний!