저는 학교에서 쓰고있는 앱과 서버 백엔드 사이의 통신을 보호하기 위해 노력하고 있습니다. 나의 초기 계획은 안드로이드 클라이언트와 PHP 서버 사이의 Diffie-Hellman 교환을 설정하는 것이었다. 그러나 SSL은 공개 키 교환 프로토콜과 매우 유사하게 (정확하게 이해하면 동일 할 수도 있음) 사용하며 더 많은 기본 지원과 더 나은 문서를 가지고있는 것으로 나타났습니다.자체 서명 된 SSL 대 모바일 응용 프로그램 용 Diffie-Hellman 교환?
Diffie-Hellman 교환을 설정하는 것보다 내 인증서가 하드 코딩 된 인증서로 자체 서명 SSL로 전환 하시겠습니까? 하나 더 나은 네트워크/배터리/CPU 성능을 제공합니까?
두 방법 모두 Man-in-the-middle 공격으로부터 실제로 보호하지 못한다는 것을 알고 있지만,이 시점에서 내 우선 순위는 단순히 도청자로부터 보호하는 것입니다.
SSL을 사용하십시오. 이미 완료되었으므로 올바르게 사용하면 MITM에 취약하지 않습니다.
+1, 동의했습니다. 당신이 그것을 피할 수 있다면 자신의 암호 시스템을 굴리지 말고, 항상 그것을 피하려고 노력해야한다. – Dev
이전 작성자가 말했듯이, DH는 MITM 공격에 취약하므로이 방법을 사용하지 마십시오.
사용자 자체 서명 된 SSL. 이렇게하면 데이터 무결성과 기밀성이 보장됩니다. SSL은 MITM에 취약하지 않으며 성능이 매우 빠릅니다. SSL의 성취도에 구글 조사 ... 클라이언트에 https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
가져 오기 서버 인증서는 클라이언트는 서버와 SSL 핸드 셰이크를 할 수 있도록.
나는 -1을 넣을 예정 이었지만 이것이 첫 번째 대답이기 때문에 나는하지 않을 것이다. [1] DH의 기본적인 구현 만이 MITM에 취약합니다. 인증을 통한 DH 구현은 그렇지 않습니다. [2] 자체 서명 된 SSL 인증서는 가짜 보안 성이며 MITM의 적용을받습니다. 누구나 인증서 교환을 가로 채고 자체 서명 된 인증서를 다른 자체 서명 된 인증서로 대체 할 수 있습니다. 그 사이에 앉아서 트래픽을 암호화/암호 해독하면 실제 서버와 통신하는지 여부를 이해할 수 없습니다. 나쁜 생각. 인증서를 올바르게 사용하려면 신뢰할 수있는 당사자가 인증서에 서명해야합니다. – oleksii
@oleksii 그러나 앱에서 자체 서명 된 인증서를 하드 코딩하면 자체 서명 된 인증서가 신뢰의 루트가되며 아무런 문제가 없습니다. – ntoskrnl
@ntoskrnl 그렇게 할 수는 있지만 인증서 유지 관리에서 만료, 해지, 확장 성 문제가 발생합니다. 또한 근본적인 결함이 있습니다. 다른 사람이 신뢰하지 않는 것을 신뢰하지 못합니다. 자체 테스트를 위해 자체 서명 된 인증서를 사용하는 것은 완벽합니다. 하지만 프로덕션 코드에는 없습니다. – oleksii
SSL은 DH뿐만 아니라 다른 키 교환 프로토콜을 사용할 수 있습니다. 또한 키 교환은 그림의 일부일뿐입니다. 실제로 제대로 작동하더라도 프로토콜이 실제로 안전해야하는 다른 많은 것들이 있습니다 (키 유도, 무결성 검사, 재생 보호 등). 아래에서 SSL 사용 방법을 배우십시오. –