HTTPS 연결 과정과 중간자 공격 및 하이재킹에 대한 자세한 설명

3. 공개 키 반환

4. 클라이언트 확인 공개 키 클라이언트는 공개 키를 받은 후 먼저 발급 기관이나 만료 시간 등 키가 유효한지 확인합니다. 문제가 발견되면 예외가 발생하여 인증서에 문제가 있음을 알려줍니다. . 문제가 없으면 클라이언트 키로 임의의 값을 생성한 다음 서버의 공개 키로 암호화합니다.

클라이언트는 서버의 공개키로 키를 암호화한 후 서버로 보냅니다.

서버는 암호화된 키를 수신한 후 개인 키로 이를 해독하여 클라이언트의 키를 얻습니다. 그런 다음 서버는 전송할 콘텐츠와 클라이언트의 키를 대칭적으로 암호화하므로 키를 알 수 없으면 어떤 내용인지 알 수 없습니다. 전송됩니다.

서버는 암호화된 콘텐츠를 클라이언트에 전송합니다.

클라이언트는 암호화된 콘텐츠를 얻은 후 이전에 생성된 키를 사용하여 이를 해독하고 콘텐츠를 얻습니다.

https는 절대적으로 안전하지는 않습니다. 아래 그림과 같이 중간자 하이재킹 공격은 클라이언트와 서버 사이의 모든 통신 콘텐츠를 얻을 수 있습니다.

중간자 하이재킹의 이유는 서버 인증서와 도메인 이름이 확인되지 않았거나 확인이 불완전하기 때문입니다. 편의상 https 요청에는 오픈 소스 프레임워크의 기본 확인 방법이 직접 사용됩니다.

발리처럼

확인http3.0

예방법:

예방법은 두 가지가 있습니다

1. 상대적으로 보안 요구 사항이 높은 앱의 경우 클라이언트 측에 인증서를 미리 내장하여 인증서를 잠글 수 있습니다. 그러나 일부 은행 앱과 같이 클라이언트 인증서와 서버 인증서가 완전히 일치하는 경우에만 통신이 허용됩니다. , 이 방법은 인증서 만료 문제라는 문제에 직면합니다. 인증서에는 특정 유효 기간이 있기 때문에 사전 내장된 인증서가 만료되면 강제로 업데이트하거나 사용자에게 인증서를 다운로드하도록 요구하여 해결할 수 있습니다.

발리를 예로 들어보겠습니다. 검증은 다음과 같이 구현됩니다

사전 내장된 인증서를 통해 SSLSocketFactory를 생성합니다.

으아악

SSL 및 도메인 이름으로 확인된 연결을 생성하세요

2 일반적인 보안 요구 사항이 있는 앱의 경우 도메인 이름, 인증서 유효성, 인증서 키 정보 및 인증서 체인을 확인할 수 있습니다

발리를 예로 들어 HTTPSTrustManager에서 checkServerTrusted 메소드를 다시 작성하고 강력한 도메인 이름 확인을 활성화하세요

현재 많은 애플리케이션이 H5 페이지를 로드하기 위해 webview를 사용합니다. 서버가 신뢰할 수 있는 CA에서 발급한 인증서를 사용하는 경우 webView.setWebViewClient(webviewClient) 시 WebViewClient의 onReceivedSslError()를 오버로드합니다. 인증서 오류가 발생하면 handler.proceed를 직접 호출합니다. 오류를 무시하고 인증서 문제가 있는 페이지를 계속 로드합니다. handler.cancel()이 호출되면 인증서 문제가 있는 페이지 로드를 종료할 수 있습니다. 위험 메시지를 표시하고 로드 여부를 사용자가 선택하도록 합니다. 보안이 필요한 경우 레벨이 상대적으로 높고 페이지 로드가 직접 종료되어 네트워크 환경이 위험하다는 메시지가 사용자에게 표시될 수 있습니다.

handler.proceed()를 직접 사용하는 것은 권장되지 않습니다. Webview가 https를 로드하고 서버 인증서에 대한 강력한 확인이 필요한 경우 HttpsURLConnection을 사용하여 onPageStarted()에서 인증서를 강력하게 확인하여 서버 인증서를 확인할 수 있습니다. 확인에 실패하면 웹 페이지 로드를 중지합니다. 물론 이로 인해 웹 페이지의 로딩 속도가 느려지고 추가 최적화가 필요합니다. 구체적인 최적화 방법은 이 논의 범위를 벗어나므로 여기서는 자세히 설명하지 않습니다.