Альтернатива SSL - «Ручное» шифрование?

Question

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

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

Код JavaScript:

var transfer_key = 'whatever'; 
function encrypt(data, key) {...}
function decrypt(data, key) {...}

function send_data_to_server(url, data)
{
    $.post(url, {'data' : encrypt(data, transfer_key) }, function(response) {
        var decrypted_response = JSON.parse(decrypt(response));
    });
}

Код PHP:

$data = $_POST['data']; 
$transfer_key = 'whatever'; 
$storage_key = 'whatever2'; 

function encrypt($data, $key) {...}
function decrypt($data, $key) {...}

databaseQuery('INSERT INTO table VALUES (?)', encrypt($data, $storage_key)); 

$decrypted_data = decrypt($data, $transfer_key); 
$response = processData($decrypted_data); 

echo encrypt($transfer_key, $response); 

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

Будет ли это хорошей альтернативой SSL?Как я могу реализовать этот тип шифрования таким образом, чтобы его было сложнее победить?Есть ли какие-то конкретные недостатки этого подхода?

Я, вероятно, найду библиотеку JS, которая заботится о шифровании и использует расширение PHP mcrypt для серверной части.Я думал о Blowfish, может быть, AES256, но я не уверен, какой из них дает мне лучшее соотношение силы шифрования к потреблению памяти.

Совет?

Answer 1

Э-э-эУдачи с этим.Вы смотрели спецификацию TLS ?Как вы думаете, вы можете придумать что-то адекватное, что будет проверено миллионами людей?

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

SSL был разработан экспертами в этой области, и они наверняка тоже сначала подумали, что их протокол был абсолютно неразрывным.Но тогда была версия 2, затем 3, затем TLS v.1, v1.1 и теперь 1.2.

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

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

Редактировать:

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

1) Как бы вы сделалиобмен ключами?Чтобы AES работал на обоих концах, вам необходимо выполнить Обмен ключами , для симметричного шифрования обе стороны должны иметь один и тот же ключ.Как вы сказали, вы хотели бы генерировать его случайным образом на клиенте - пока все хорошо.Первая проблема - вам нужно сгенерировать безопасное случайное число - иначе, например, с помощью встроенного генератора случайных чисел Javascript - злоумышленники смогут предсказать ваши случайные числа через некоторое время.

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

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

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

4) Как только вы освоите это, вывсе еще подвержены более сложным видам атак, таким как повторные атаки , атаки "человек посередине" , атаки отражением , ...

5) Возможно, вам также понадобится Perfect Forward Secrecy , чтобы после взлома ключа злоумышленник не смог расшифровать любые прошлые данные.Для достижения этой цели вам потребуется Diffie-Hellman (предпочтительно в форме Elliptic Curve Cryptography ).

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

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

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

РЕДАКТИРОВАТЬ: Ну, в последнее время были некоторые атаки, но почти все атаки использовали "человеческий фактор" в этих протоколах, атакуя сертификаты открытых ключей, которые поддерживают протокол (Comodo, DigiNotar и т. Д. выдающиеся примеры) или более загадочные особенности протокола, такие как согласование алгоритма и т. д., но BEAST был впервые, когда TLS был успешно атакован на уровне криптографии, что одновременно интересно и страшно потому что основы этой атаки были известны некоторые годы сейчас.

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

Answer 2

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

В этом нет ничего безопасного.Ничего такого. Ничего .

Он мертв с самой первой отправки этого javascript ... Мне все равно, какие у вас длинные ключи или насколько случайна соль.

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

Если то, что у вас есть, стоит зашифровать, то это стоит дополнительных $ 240 / год, чтобы сделатьэто правильно.Пожалуйста, отойдите от выступа и сделайте это правильно.

Answer 3

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

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

• строка шифрования
• обмен ключами
• Аутентификация

Для шифрования вам необходимо внедрить шифр. Это выполнимо.

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

Аутентификация необходима для прекращения атак «человек посередине», и для этого требуется какой-то внеполосный обмен информацией (например, телефонный звонок или инфраструктура PKI). Вопрос о том, работает ли это на самом деле, весьма спорен, даже для SSL.

Так что, в принципе, если вы можете реализовать все эти компоненты через HTTP, то в принципе должна быть возможность запустить безопасную связь через HTTP. В конце концов, SSL делает то же самое, он запускает безопасный канал через небезопасную среду. По сути, вы хотите реализовать SSL в JavaScript. Проверьте ASSL , они попробовали что-то подобное.

Answer 4

Мой совет - придерживаться SSL / TLS.Я думаю, что это облегчит вашу жизнь, а также обеспечит признание вашей отрасли решений.

Вместо статического IP-адреса, могли бы вы использовать DynDNS (или аналогичную службу) с самозаверяющим сертификатом?