티스토리 뷰

HTTPS(Hyper-Text Transfer Protocol Secure)의 S는 secure 입니다.
즉, 기존의 HTTP 사이트보다 안전하다는 얘기입니다.
무엇으로부터 안전할까요? 크게 둘로 나뉩니다.
먼저, 내가 어떤 웹사이트에 보내는 정보를 다른 누군가 훔쳐보지 못하게 합니다.
여러분이 네이버에 접속해서 아이디와 비밀번호를 입력하고
로그인 버튼을 누르면 이 두 정보가 인터넷을 타고 네이버의 서버로 전송되는거죠.
그런데 그냥 HTTP로 보내면 이 암호가 입력한 텍스트 그대로, 누구든 알아볼 수 있는 형식으로 보내져요.
만약 누군가가 이 정보를 중간에 들여다보면 그 누군가는 여러분의 네이버 아이디와 비번을 알게 되는거죠.

일반적으로는(권장X) 사이트들, 앱들에 같은 아이디와 비번을 설정하니까 사실상 여러분의 모든 사이버 정보가 털린다고 볼 수 있습니다.
HTTPS는 이 정보를 네이버만 알아볼 수 있는 뒤죽박죽인 텍스트로 변경해서 실어보내요.
나쁜 사람이 들여다보도 뭐라고 쓴건지 알아볼 수 없도록 말이죠.

다른 하나는, 여러분이 접속한 사이트가 진품인지, 신뢰할 수 있는 사이트인지를 판별해주는거예요.
네이버에 들어가려고 링크를 클릭했는데 알고보니 '네이놈'이라는 피싱 사이트인 경우가 있어요.
거기에 네이버 아이디랑 비밀번호를 입력해버리면 이 피싱 사이트가 여러분의 네이버 계정을 알게 되겠죠.
은행 온라인뱅킹 사이트의 경우 더 큰일일테구요. HTTPS는 이런 수상한 사이트를 걸러낼 수 있도록 해줍니다.
기관으로부터 검증된 사이트만 주소에 HTTPS 사용이 허가되고 이제 그냥 HTTP를 사용하는 사이트들은 주소창에 이런 '안전하지 않다'는 표시가 뜨게 되거든요.

요약하자면 HTTPS는
1. 내가 사이트에 보내는 정보들을 제 3자가 못 보게 한다.
2. 접속한 사이트가 믿을 만한 곳인지를 알려준다.
이 두 가지 덕분에 그냥 HTTP보다 안전하다.

여러분의 컴퓨터에서 네이버 웹사이트에 접속하면 컴퓨터는 네이버 서버에 대략 이렇게 생긴 메세지를 보내요.

그럼 네이버 서버는 여러분 컴퓨터에 이런 메세지를 보내죠. 컴퓨터 지식이 있어도 사람이 이런 걸 술술 읽는 건 무리에요
그럼 컴퓨터는 읽겠죠? 아뇨, 아직은 못읽습니다. 이 메세지가 어떤 형식으로 작성됐는지를 모르기 때문이에요.

이 문자가 0인지 O인지 ㅇ인지 알려면 이게 숫자인지 알파벳인지 한글인지 알아야 하고

이 사진이 어떤 상황인지 알려면 이게 바둑인지 오목인지 알아야 하죠.
HTTP는 인터넷상의 커뮤니케이션에 사용되는 형식들 중 하나입니다.

우리 사람은 이런걸 보면 대번에 우편 형식이라는 걸 알고 이게 수신자, 이건 주소, 우편번호, 연락처라는 걸 알지만 내 컴퓨터에서 네이버 서버에 요청을 보낼 때는 이것들을 보낼 때마다 '자 이 메시지들은 HTTP(S) 형식이야'하고 주소창에 써서 일일이 명시를 해줘야

네이버 서버는 이걸 HTTP 형식으로 읽어본 다음 '이런이런 페이지를 보여달라는거구나'하고 알아듣고서 그에 맞는 응답을 이렇게 작성해서 보내고

내 컴퓨터는 이걸 HTTP형식에 따라 해독해서 이런 화면을 보여주게 됩니다.
이 HTTP 형식에 앞서 앞서 말한 보안 기능까지 추가한 게 HTTPS인거죠.

대칭키 VS 비대칭키

전쟁에서 아군에게 편지로 메세지를 보낼 때 중간에 적이 편지를 탈취해도 이를 알아볼 수 없도록 하려면 편지의 내용을 암호화해야겠죠. 그 암호화된 메시지는 아군만 읽을 수 있어야 할 거구요. 그래서 옛날부터 이를 위한 방식들이 고민되어 왔어요.

그동안 널리 사용되어 온 건 대칭키 방식입니다.
메시지를 보내는 쪽과 메시지를 받는 쪽이 메시지를 암호화하고, 이를 다시 메시지로 바꾸는 즉, 복호화하는 같은 방식을 공유하는 거죠.
예를 들어 양쪽 모두 a는 27, b는 9, c는 51 이런 표를 대칭으로, 즉 양쪽이 똑같이 가지고 있다면 중간에 편지가 가로채여도 본문이 노출될 걱정 없이 얼마든 메시지를 주고받을 수 있겠죠. 이 표만 노출되지 않는다면요.

컴퓨터에서 사용하는 '대칭키'란 건 이 표와도 같아요.
이런 임의의 문자열이 있어요. 이걸 '키'라고 부릅니다.

4에 3을 곱하면 12가 되죠. 상대방에게 보내고자 하는 메시지를 이 '키'와 함께 어떤 알고리즘에 넣고 돌리면 이처럼 전혀 알 수 없는 암호문이 만들어져요.

12에서 4를 얻어내려면, 3으로 나눠야 하는것처럼 이 암호문을 받은 사람이 이걸 해독하려면 이 키값을 넣고 이 알고리즘을 거꾸로 돌리면 됩니다. 이 과정을 복호화라고 하죠.
이 '키'값을 알지 못하면 절대 이 암호문을 해독할 수 없어요.

이제 내 컴퓨터와 네이버 서버에 이 동일한 키가 있다면 대칭이란게 양쪽이 똑같다는 뜻이잖아요.
내가 로그인할 때 실어보내는 비밀번호를 이걸로 암호화하고 네이버에서는 이를 복호화해서 인식할 수 있겠죠.
중간에 이걸 누가 훔쳐보더라도 알아볼 수 없을거구요.

근데 문제는 어떻게 이 동일한 키를 애초에 양쪽이 공유하느냐에요. 결국 한 번은 한쪽에서 다른 한쪽으로 이 키를 전송해야 하는데 중간에 이걸 누군가 훔쳐본다면 말짱 꽝이 되는거죠.
문제가 원점으로 돌아와버렸죠. 이게 대칭키의 한계예요.

이를 보완한 새 방식이 1970년대에 수학자들에 의해 개발됐어요.
비대칭키, 또는 공개키라 불리는 시스템이죠. 여기에는 두 개의 키가 사용돼요. 각각 A키와 B키라고 부를게요.
이 둘은 한 쌍이예요. 서로 다르기 때문에 '비대칭키'라고 불립니다.
이 암호화 방식을 개발자들은 보통 '공개키'라고 많이 부릅니다.
대칭키 시스템에서는 어떤 키로 암호화를 하면 같은 키로 복호화를 할 수 있었지만 여기서는 A키로 암호화를 하면 B키로만 복호화할 수 있습니다. 반대로 B키로 암호화를 하면 A키로만 풀 수 가 있죠.

네이버 서버는 이 두 키들 중 하나는 비밀로 보관하고('이걸 '개인키'라고 불러요)
다른 하나를 그냥 대중에게 공개해요. 누구나 볼 수 있도록요.(이게 '공개키'인거죠)
이제 사용자는 이 공개키로 비밀번호를 암호화해서 네이버에 보내요.
누가 가로채면 어떡하냐구요? 말씀드렸듯 같은 공개키로는 이 암호문을 풀어낼 수가 없어요.
이걸 볼 수 있는 건 이 개인키를 가진 네이버뿐인거죠.
이원리로 개인 정보들을 안심하고 네이버에 보낼 수 있는 거예요
이 사이트가 네이버인걸 어떻게 증명하느냐?
네이버에서 우리에게 보내는 정보들은 그 일부가 네이버의 개인키로 암호화가 되어 있습니다.


우리가 네이버의 공개키로 풀어서 알아볼 수 있는건 네이버의 개인키로 암호화된 정보들 뿐이겠죠.

네이놈에서 온 정보들은 네이버의 공개키로 풀리지 않기 때문에 네이버의 공개키로 열어보려고 하면 오류가 나게 됩니다.

신뢰할 수 있는 기관에서 우리에게 네이버의 공개키만 검증해준다면 우리는 이걸 기준으로 안전하게 네이버를 이용할 수 있습니다.
일단 네이버가 우리에게 뿌린 공개키 이게 정품인지 확인할 수 있어야 합니다.
네이버가 아니라 네이놈의 공개키 일수도 있으니까요.
이걸 인증해주는 공인된 민간기업들이 있습니다. Certificate Authority. 줄여서 CA라고 합니다.
아무나 차려서 될수 있는게 아니라 엄격한 인증과정을 거쳐야 CA를 할 수 있습니다.
브라우저 즉 크롬이나 사파리, 파이어폭스,엣지, 익스플로러 등의 프로그램에는 이 CA들의 목록이 내장되어 있습니다.
여러분의 컴퓨터, 정확히는 브라우저 측을 이 서버와 상대되는 개념, 즉 클라이언트라고 부릅니다.
사용자로 이해하면 됩니다.
클라이언트는 아직 이 서버를 신뢰하지 못합니다.
그래서 이 둘은 먼저 일종의 탐색과정을 거치게 되는데 이걸 handshake. 악수라고 합니다.
먼저 클라이언트는 어떤 랜덤 데이터를 생성해서 서버에 보냅니다.
이걸 받은 서버는 답변으로 역시 서버측에서 생성한 무작위의 데이터 그리고 해당 서버의 인증서를 실어서 보냅니다.
이거로 둘은 악수를 한겁니다.

그럼 이제 클라이언트는 이 인증서가 진짜인지 브라우저에 내장된 CA들의 정보를 통해 확인하게 됩니다.


비대칭키 시스템을 사용해서요.
CA의 인증을 받은 인증서들은 해당 CA의 개인키로 암호화가 되어 있습니다. 이게 진짜라면 브라우저에 저장된 그 CA의 공개키로 복호화 할 수 있겠죠
이 공개키로 복호화될수 있는 인증서를 발급할 수 있는 건 그에 대응하는 개인키를 가진 이 CA뿐이니까요
만약 이 CA리스트 중에 이 인증서가 해당하는 것이 없다면 브라우저 주소창에 이런 표시가 뜨게 되는 거구요.

그렇게 성공적으로 복호화된 인증서에는 이 서버의 공개키가 포함되어 있습니다.
지금부터 주고받아지는 데이터들은 대칭키 방식과 비대칭키 방식이 함께 혼합되어서 사용됩니다.
비대칭키 방식으로 메세지를 암호화 및 복호화하는 건 대칭키로 할 때보다 컴퓨터에 훨씬 큰 부담을 줍니다.
사이트를 이용할 때 주고받을 그 다량의 데이터를 비대칭키로 일일이 암호화, 복호화하는 건 무리라는 얘기죠.
그래서 이 데이터는 대칭키로 암호화를 합니다.
그 대칭키를 공유할 때 비대칭키를 사용합니다.
클라이언트는 악수할 때 생성된 무작위 데이터 둘을 혼합해서 어떤 임시키를 만듭니다.
이 임시키는 서버의 공개키로 암호화돼서 서버로 보내진 다음 양쪽에서 일련의 과정을 거쳐서 동일한 대칭키가 만들어집니다. 이제 이 대칭키는 서버와 이 클라이언트 둘만 가지고 있기 때문에 이후 서로 주고받아지는 메세지들을 제 3자가 알아볼 걱정이 없습니다.

'프론트엔드 > CS' 카테고리의 다른 글

[OAuth 2.0] 03. 등록  (1) 2022.10.13
[OAuth 2.0] 02. 역할  (0) 2022.10.12
[OAuth 2.0] 01. OAuth란?  (0) 2022.10.12
TCP / IP  (0) 2022.09.17
SSR / CSR / SSG 와 TTV / TTI  (0) 2022.09.15
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2024/05   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
글 보관함