항해 99 5기 TIL_87

▶ Today I Learned

 

<실전 프로젝트>

 

[HTTPS]

 

프로젝트 초반에는 제작에 초점을 맞춰 HTTP로 시작하였지만 보안을 위해 이를 HTTPS로 바꾸어주어야 한다.

이를 위해 HTTPS가 무엇인지 정리해보겠다.

 

cf) HTTP:

HyperText Transfer Protocol, 하이퍼텍스트란 참조를 통해 독자가 다른 문서로 즉시 접근할 수 있는 텍스트이다.

HTTP는 하이퍼텍스트를 전송하기 위한 통신규약이다. 쉽게 말해 인터넷에서 HTML과 같은 문서를 사용자 컴퓨터에 설치된 웹 브라우저가 웹 서버에 요청할 때의 규칙인 것이다. 기본 포트는 80번이다.

HTTP는 텍스트로 정보를 주고 받는데 네트워크 상에서 전송 신호를 가로채는 경우 데이터 유출이 발생할 수 있다.

이러한 보안 문제를 해결하기 위해 나온 것이 HTTPS이다.

 

HTTPS: HyperText Transfer Protocol Secure, HTTP에서 보안이 추가된 형태이다.

기본 포트는 443번이다. SSL 프로토콜 (Secure Sockets Layer, 암호화 기반 인터넷 보안 프로토콜,

현재 사용중인 TLS, Transport Layer Security 암호화의 전신)

 

HTTPS가 더 안전하다고 할 수 있는 이유는

1) 내가 어떤 웹사이트에 보내는 정보를 훔쳐볼 수 없음 (수신 측 웹사이트만 알아볼 수 있는 텍스트로 변경)

2) 내가 접속하려는 사이트가 믿을만한 곳인지 판별해줌

 

여기서 사용되는 방식이 아래의 두 가지 방식이다.

 

<대칭키>

과거 널리 사용, 암호화와 복호화에 똑같은 규칙을 적용

=> 해당 규칙과 언젠가 한번은 전송될 키(임의의 문자열, 암호화와 복호화에 사용될 그 규칙)가 탈취되면 제3자에게 정보가 노출될 위험성 발생

 

<비대칭키(공개키)>

 

대칭키의 문제점을 해결하고자 나온 방식

A와 B라는 각각의 다른 키를 가지고 있으며 A키로 암호화한 것은 B키로만 복호화,

B키로 암호화한 것은 A키로만 복호화 가능

자신이 보관하는 하나의 키는 개인키(Private Key), 대중에게 공개하는 키를 공개키(Public Key)라고 함

ex) 사용자가 공개키로 특정 사이트에 비밀번호를 암호화해서 보낸다면 도중 제 3자가 그 내용을 탈취하더라도

공개키로는 복호화할 수 없음, 오로지 그 사이트의 개인키로만 복호화가능하기에 비밀번호 유출 염려 X

 

 

**그 특정 사이트가 내가 이용하고자 하는 그 사이트가 맞는지 확인하고 정보를 주고받는 과정**

 

이미지 출처:

https://rachel-kwak.github.io/2021/03/08/HTTPS.html

 

사용자가 그 사이트에 정보 요청 -> 그 사이트에서 정보를 보내온 정보의 일부는 그 사이트의 개인키로 이루어져있음

이를 복호화할 수 있는 건 사용자가 지니고 있는 그 사이트의 공개키 뿐임

(다른 사이트에서 온 정보를 그 공개키를 가지고 복호화하려고 하면 오류가 날 것임)

=> 그 사이트의 공개키만 신뢰할 수 있는 기관(CA, Certificate Authority)에서 검증해준다면

안전하게 그 특정 사이트를 이용할 수 있음

 

cf) 기본적으로 우리가 이용하는 브라우저들에는 CA의 리스트가 내장되어 있음

 

클라이언트는 처음부터 서버를 신뢰하지는 못함

=> 이를 위해 handshake 라는 과정 거침

 

cf) Handshake?

클라이언트에서 서버 측에 임의의 데이터 전송 -> 서버는 그 데이터를 기반으로 무작위데이터 생성 후 인증서를 실어 클라이언트 측으로 전달하는 작업

 

인증서가 진짜인지 확인하기 위해 브라우저에 내장된 CA들의 공개키로 복호화 작업을 진행하여 검증

(CA의 인증을 받은 인증서는 CA의 개인키로 암호화 되어있기 때문)

실패 시 Not Secure 표시, 성공 시 인증서에 서버의 공개키가 포함되어 있음

 

=> 이 후로 주고 받는 데이터는 비대칭키가 아닌 대칭키 방식으로 주고 받음

(모든 데이터를 비대칭키 방식으로 암호화, 복호화하는 것은 대칭키 방식에 비해 컴퓨터에 큰 부담을 주기 때문)

 

cf) 여기서 대칭키 방식의 문제점을 막기 위해 서버에 대칭키를 공유할 때 비대칭키 방식을 사용함

(Handshake 당시 클라이언트가 보낸 데이터 + 서버로 부터 받은 데이터를 혼합하여 임시 키 생성,

해당 임시키를 서버의 공개키로 암호화해서 서버로 전달 -> 서버는 개인키로 임시키를 복호화하고

클라이언트와 서버 양측에서 일련의 과정을 거쳐 양측에 동일한 대칭키가 생성됨

-> 이후에는 그 대칭키를 주고 받아야 할 필요가 없으므로 중간에 암호화된 데이터가 탈취되더라도 문제 없음)

 

세션이 종료되면 대칭키는 폐기, 대칭키는 이렇게 매번 랜덤의 다른 키가 생성되므로 설령 유출된다 하더라도 문제 없음

 

 

<HTTPS의 특징>

 

1) 내가 어떤 웹사이트에 보내는 정보를 훔쳐볼 수 없음 (수신 측 웹사이트만 알아볼 수 있는 텍스트로 변경)

2) 내가 접속하려는 사이트가 믿을만한 곳인지 판별해줌

3) getUserMedia()를 통한 사진 촬영이나 오디오 녹음, 또는 프로그레시브 웹 앱과 같은 강력한 웹 플랫폼 신기능들은 실행하려면 사용자의 명시적인 권한 허락이 요구됨. Geolocation API와 같은 오래된 API들도 실행할 때 권한이 필요하도록 업데이트되고 있는데, HTTPS는 이러한 새 기능과 업데이트된 API에 대한 권한 허락을 가능하게 해줌

4) 네이버, 다음은 물론이고 구글 역시 검색 엔진 최적화(SEO: Search Engine Optimization) 관련 내용을 HTTPS 웹사이트에 대해서 적용 중. 즉, 키워드 검색 시 상위 노출되는 기준 중 하나가 보안 요소임

5) HTTPS라고 해서 항상 안전한 것은 아님. 신뢰할 수 있는 CA 기업이 아니라 자체적으로 인증서를 발급하거나

신뢰할 수 없는 CA 기업을 통해서 인증서를 발급받을 수도 있기 때문임

 

HTTPS 적용에는  하단의 링크를 참조해보자.

 

Amazon Certificate Manager를 이용하여 HTTPS 설정하기

https://happiestmemories.tistory.com/48

ACM이 아닌 다른 SSL인증서로 HTTPS 설정하기 (Certbot 사용)

https://velog.io/@moonyoung/HTTPS-%EC%84%A4%EC%A0%95%ED%95%98%EA%B8%B0

 

어느쪽이든 핵심 내용은

1) 홈페이지 ip와 도메인을 연결시킬 것,

2) SSL 인증서를 발급받을 것,

3) 서버에 해당 사실을 등록할 것

 

이라고 생각한다.

 

(참고로 우리의 프로젝트는 ACM을 사용하여 HTTPS를 설정해놓았다.)

 

▶ 느낀 점

 

과거 HTTPS를 공부할 때는 그저 S가 Secure의 약자이니 HTTP가 붙은 사이트보다 좀 더 안전한 것이라고만 생각했다.

하지만 이렇게 좀 더 깊게 조사해보니 알아야 할 지식이 꽤나 많아서 놀라웠다.

개발의 세계는 역시 깊이 알면 알 수록 알아야 할 것이 많다.

지금 모든 것을 알 수는 없지만 이렇게 조사해두었으니 다음 번에 활용할 일이 있다면 더욱 수월하게 활용할 수 있으리라 본다.

 

▶ 공부 시 참고 링크들

 

HTTP와 HTTPS

https://rachel-kwak.github.io/2021/03/08/HTTPS.html

https://dololak.tistory.com/541

 

유튜브 '얄팍한 코딩사전' - HTTPS 편

https://www.youtube.com/watch?v=H6lpFRpyl14

 

SSL

https://www.cloudflare.com/ko-kr/learning/ssl/what-is-ssl/