Поскольку это не бюджетный хобби-проект, я не могу позволить себе сертификат. Давайте просто скажем, что https - это не вариант.
, когда дело доходит до этого - вы можете просто создать свой собственный CA (центр сертификации), которому доверяют в рамках проекта, и вы хороши для go.
Существует также несколько способов получить бесплатный доверенный сертификат (например, Letsencrypt)
Обычная причина невозможности использования TLS - медленное низкоуровневое оборудование (например, Arduino), где асимметрия c операции будут занимать очень много времени (невозможно использовать RSA). Или школьный образовательный проект. В противном случае вы можете пересмотреть.
Будет ли это безопасно?
Short - нет. Долго - зависит - защищен от чего?
Если вы проверяете стандарт TLS , протокол делает много вещей (проверяет доверие к сертификату, создает и подписывает эфемерные пары ключей, согласование ключей сеанса, настройка каналов, ..) и по уважительным причинам. Использование ярлыков заставит ваш протокол использовать разные векторы атаки, которые будут смягчены на каждом шаге или уровне.
Для начала - ваш протокол (первая версия) будет уязвим для атаки MiM (человек посередине). Любой может представить ложный сервер. Используя прямое доверие (фиксированная пара ключей сервера - я полагаю, это другой подход?), Вы смягчаете это, но другие проблемы остаются нерешенными.
Клиент отправляет запрос rest с одним аргументом в формате json и содержит каждый необходимый параметр. Зашифровано с использованием: key1
Теоретически это может работать при передаче правильно зашифрованных сообщений , если все сделано правильно . Вы не указали много подробностей, поэтому мы не можем оценить другие факторы (например, повторную атаку, целостность, ..)
Передача зашифрованных сообщений по незащищенному каналу - это уже рассматривается в сквозном зашифрованном протоколы обмена сообщениями (например, протокол передачи сигналов). Вы можете взглянуть на тезисы / использовать протоколы, чтобы обезопасить себя, если вам действительно нужно пропустить TLS.