내 호스트와 관련된 몇 가지 문제로 인해 서버에서 SSL 인증서를 사용할 수 없으며 (아직 공급자를 변경할 준비가되지 않았습니다) 따라서 HTTPS를 사용하십시오. 이 서버는 몇 대의 클라이언트 컴퓨터와 통신하며 다소 비밀스러운 데이터를 전송합니다.HTTPS를 사용하는 대신 수동 AES 암호화 적용
HTTPS 대신 대신 A30 암호화 (보내기 전에 클라이언트의 암호화, 처리 전에 서버의 암호 해독)을 사용하는 것이 합리적입니까?
이는 배포 환경에 따라 다릅니다.
SSL/TLS (및 HTTPS)를 웹 브라우저에서 사용하기 위해 자체 암호화 프로토콜로 대체하는 것은 안전하지 않은 방식으로 제공되는 JavaScript 코드를 사용하므로 항상 나쁜 생각입니다 (자세한 내용은 this question on Security.SE 참조).
클라이언트가 웹 브라우저가 아닌 경우 더 많은 옵션을 사용할 수 있습니다. 특히, 전송 레벨 보안 (HTTPS가 사용하는 것) 대신 메시지 레벨 보안을 구현할 수 있습니다.
HTTP를 사용하여 메시지 수준 보안을 표준화하려는 여러 시도가 있습니다. 예를 들어 :
WS-Security, SOAP의 세계를 지향합니다. 당신이 도구를 기존의 재사용하려는 경우 (당신이 이메일에서와 동일한 방법으로)
아마도 더 간단하게, 당신은 HTTP 메시지의 실체를 암호화 S/MIME 또는 PGP를 사용할 수 있습니다. HTTPS와 달리 URL 또는 HTTP 헤더를 보호하지는 않지만 중요한 데이터를 입력하지 않으면 충분할 수 있습니다.
"원시 암호화"(예를 들어 AES를 직접 사용)를 수행할수록 수동으로 다른 측면의 보안을 구현해야합니다 (일반적으로 원격 파티의 신원을 확인하고 키를 미리 공유하는 문제).
답변 해 주셔서 감사합니다. 매우 감사드립니다. 클라이언트 자체는 웹 브라우저가 아니라 오히려 일반 응용 프로그램 (Java)입니다. – Zar
자주 변경되지 않는 작은 클라이언트 목록이있는 경우 SSH를 사용하여 자체 SSL 터널을 구현할 수 있습니다. 클라이언트에서 수행; nulluser가 example.com에는 쉘 또는 파일을 액세스 할 수 없습니다
ssh -D 4444 [email protected] -N
.
그런 다음 foxyproxy 허용 목록 설정을 추가하십시오. example.com의 경우 클라이언트 브라우저는 localhost:4040 프록시를 사용합니다.
해킹입니다. 완전히 조정할 수는 없지만 작고 정적 인 고객 수에 대해서는 말할 수있는 것처럼 작동하며, 완전히 안전하면서 바퀴를 다시 발명하지 않는 이점이 있습니다.
답변 해 주셔서 감사합니다!클라이언트의 수는 슬프게도 변할 것입니다. (대개 1 년에 한 번), 잘하면 ~ 100 명의 클라이언트가 있습니다. – Zar
이드는 아주 간단합니다. 클라이언트 시스템에서 터널을 구성해야 할 수도 있습니다. 괜찮 으면 설명을 해줄 수 있습니다. – lynks