본문 바로가기
React TIL

[React] Day_50 데일리 정리

by 림졍 2024. 11. 28.
728x90
반응형

이번 배포 나만 느렸어?

 

결국 배포에서 눈물 바가지로 흘리며 누더기 골렘엔딩으로 과제 끝.

챌린지반 내일 발표인데.. 밤을 샛던 림졍림졍은 너무 피곤해서

한시간 자고 우다다다다다 적고..

이제 드디어 쉬는중.,..

내일.. 또 발제겠지?

내일 ..또 바쁘겠지?

내일.. 또.. 주말 사라졌겠지?

잠은 또 못자겠지?

하하.. 챌 스터디반 우다다 또 해보겠습니다.

라쯔고.

 

 

 

챌린지반 스터디 정리 - HTTP vs HTTPS

발표자료도 짤로 도배하는 짤생짤사 림졍.. (긁어와서 오늘은 오랜만에 존댓말입니다.)

 

놀랍게도 이게 인트롭니다. 개쩔죠?

 

1. HTTP ( Hyper-Tesx Transfer Protocol )

웹에서 데이터를 주고받는 서버-클라이언트 모델의 프로토콜

(그냥 간단하게 말하면요.. 인터넷 상에서 서버랑 클라이언트가 주고받는 대화 형식 중 하나입니다.)

 

요청과 응답

- 브라우저는 아래와 같은 HTTP 요청을 서버로 보냅니다.

GET /index.html HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept-Language: ko-KR
  • GET /index.html HTTP/1.1 : HTTP 요청 메서드, URL, HTTP 프로토콜 버전 정보
  • 나머지 : HTTP 요청의 헤더, key:value 쌍으로 이루어짐
  • 헤더 : 웹사이트 도메인 호스트, 언어, 사용자의 브라우저 등 서버가 필요한 정보 전달

- 요청에 문제가 없다면, 서버는 아래와 같은 응답을 브라우저에게 돌려줍니다.

HTTP/1.1 200 OK
Date: Sat, 09 Oct 2023 14:28:02 GMT
Server: Apache
Content-Type: text/html

<html>
...
</html>
  • HTTP/1.1 200 OK : HTTP 프로토콜 버전 정보 및 상태코드
  • : key:value 쌍, 모두 헤더 (응답의 헤더, 브라우저가 필요한 정보 전달해줌)

- HTTP의 한계점

브라우저-서버, 데이터를 일반 텍스트로 교환 (누구든 알아볼 수 있습니다..!)

그냥 바로 보내주는 너란 친구들..


→ 데이터를 암호화하지 않고 전송하기 때문에 노출위험이 증가되어

제 3자가 데이터를 가로채고 읽을 수 있는 위험이 높아질 수 있다는 한계가 존재합니다.

 

벌써 아찔하지 않나요 🫨??

 

+) 다들 사이트 별로 아이디와 비밀번호 다르게 하고 다니지 않잖아요.. (솔직히 말해봐요..,)

계정 정보가 털린다. + 타 사이트에서도 같은 아이디 비번 설정을 하고 다니는 우리같은 유저

→ 모든 사이버 정보가 털린다고 생각하면 될 겁니다..

해당 문제를 해결하고자 나타난 친구가 있었으니.. 바로 밑에서 소개하도록 하겠습니다.

 

 

 

2. HTTPS ( Hyper-Tesx Transfer Protocol Secure )

HTTP의 보안 취약성을 강화해서 나온 더 안전한 버전

 

 

→ S는 Secure의 S입니다. (MBTI ‘S’ 아닙니다.🙅🏻!)

거의 대부분 공신력 있는 사이트들은 HTTPS를 사용한다고 보면 됩니다.

 

2.1 HTTPS가 HTTP보다 안전한 이유

 

HTTPS가 HTTP보다 안전이유는 아래와 같습니다.

  1. 내가 사이트에 보내는 정보들을 제 3자가 못 보게끔 만든다.
  2. 접속한 사이트가 믿을만한 곳인지 알려준다.

보다 자세한 내용은 원리에서 진행될 예정이니 우선 이렇게만 알고 가보자구요 ^-^)b

 

 

2.2 원리 (대칭키 비대칭키)

⇒ 위의 두가지 보안기능이 어떤 원리로 구현되는지 알아보도록 하겠습니다.

 

1) 내가 사이트에 보내는 정보들을 제 3자가 못 보게 한다.

해당 내용을 알기 위해선 대칭키 vs 비대칭키의 개념부터 알아야 합니다.

두가지 모두 제 3자에게 노출되어도 알아볼 수 없도록 메시지 암호화 및 복호화 과정에 필요한 키입니다.

 

(눈에 잘 보이진 않지 만 나름 그림을 그려봤습니다. ..?)

 

 

- 대칭키

동일한 키값을 활용하여 암호화 및 복호화를 진행 → 보안을 유지하는 방식

그동안 널리 사용되어 온 키 방식이지만

한쪽에서 키값을 전송해야 사용될 수 있다는 한계점이 존재합니다...

또한 전송 과정에서 제 3자에게 노출된다면, 키값 존재의 이유가 사라진다는 단점 또한 존재합니다.

cf. 암호화 = 기존값에 키값을 추가하여 제 3자에겐 알 수 없는 암호로 만드는 과정

복호화 = 기존 알고리즘을 거꾸로 돌려 생성된 암호에 키값을 적용시켜 기존값으로 돌리는 과정

 

 

- 비대칭 키

대칭키의 한계점을 개선하기 위해 탄생한 키로, 개발자들 사이에서는 공개키라고도 불립니다.

 

- 대칭키 vs 비대칭키 (정리)

간단하게 각 시스템에 대해 설명하자면 아래와 같습니다.

  • 대칭키 시스템:
    • 암호화와 복호화에 같은 키를 사용합니다.
    • 간단하지만, 키를 안전하게 공유하는 것이 어려운 점이 있습니다.
  • 비대칭키 시스템:
    • 한쪽에서 암호화하면 다른 키로만 복호화가 가능합니다.
    • 쉽게 말해, **자물쇠(공개키)**와 열쇠(개인키) 구조라고 생각할 수 있습니다.

 

- 비대칭키의 동작 원리

  1. 두 가지 키 중 하나는 **비밀(개인키)**로 보관하고, 나머지 하나는 **공개(공개키)**하여 누구나 볼 수 있도록 합니다.
  2. 사용자는 공개키로 데이터를 암호화해 서버에 전송합니다.
    • 공개키로 암호화한 데이터는 같은 공개키로 복호화할 수 없습니다.
    • 오직 개인키를 가진 서버만 복호화가 가능합니다.

이 원리를 통해, 가로채더라도 데이터를 풀 수 없기 때문에 안전하게 개인 정보를 전송할 수 있습니다.

 

 

2) 접속한 사이트가 믿을 만한 곳인지를 알려준다.

 

- 비대칭키의 역할: 신뢰성 확보

  • 접속한 사이트가 믿을 만한지 확인할 수 있습니다.
  • ex): ‘이 서버가 진짜 네이버인지 어떻게 알 수 있을까?’
  • 서버는 특정 데이터를 개인키로 암호화해 사용자에게 전송합니다.
    • 사용자는 공개키를 이용해 이 데이터를 복호화할 수 있습니다.
    • 만약 데이터가 공개키로 풀리지 않는다면, 해당 정보는 신뢰할 수 없는 출처에서 온 것이기 때문에 오류가 발생합니다.
  • 공개키는 신뢰할 수 있는 인증 기관에서 검증받습니다.
    • 이를 통해 사용자는 서버가 안전한지 판단할 수 있습니다.

 

3. HTTPS가 실제로 구현되는 과정 (복잡함 주의)

HTTPS의 동작 원리는 간단히 설명하기 어렵지만, 여기서 주요 흐름을 알아보겠습니다.

 

1. 서버 공개키 검증: CA (Certificate Authority, 인증 기관)

서버가 공개한 공개키가 신뢰할 수 있는 키인지 확인해야 합니다.

이를 검증하는 역할은 CA(인증 기관)가 담당합니다.

CA 리스트들

  • CA는 공인된 민간 기업으로, 엄격한 인증 과정을 거쳐야만 등록될 수 있습니다.
  • 브라우저(크롬, 사파리 등)에는 CA 목록이 내장되어 있습니다.

2. 브라우저 - 서버 간 Handshake

클라이언트(사용자)와 서버는 악수(handshake)라는 탐색 과정을 통해 신뢰를 쌓습니다.

① 클라이언트 → 서버:

클라이언트는 랜덤 데이터를 생성하여 서버로 전송합니다.

 

 

② 서버 → 클라이언트:

서버는 자체적으로 생성한 랜덤 데이터와 함께 자신의 인증서를 클라이언트로 보냅니다.

 

 

이렇게가 악수입니다 ^-^)b 어때요, 참 쉽죠?

 

3. 인증서 검증

클라이언트는 서버가 보낸 인증서의 진위 여부를 확인합니다.

 

  • CA 인증서는 해당 기관의 개인키로 암호화되어 있습니다.

  • 브라우저는 내장된 CA의 공개키로 복호화하여 인증서를 검증합니다.
  • 만약 인증서가 유효하지 않다면, 브라우저는 “Not Secure” 경고를 표시합니다.

 

 

4. 대칭키 생성

인증이 완료되면, 클라이언트와 서버는 임시 대칭키를 생성합니다.

  • 클라이언트는 핸드셰이크 중 생성된 랜덤 데이터를 혼합하여 임시 키를 만듭니다.
  • 이 대칭키는 서버의 공개키로 암호화되어 전송되며, 서버에서 개인키로 복호화됩니다.
  • 클라이언트와 서버는 이제 동일한 대칭키를 공유합니다.

 

5. 데이터 암호화 전송

이후 주고받는 데이터는 대칭키 암호화를 통해 보호됩니다.

  • 비대칭키 방식은 처리 속도가 느리기 때문에, 이후 대량의 데이터는 대칭키 방식으로 암호화됩니다.
  • 대칭키는 클라이언트와 서버 간 비밀로 유지되며, 외부에서 알아낼 수 없습니다.

 

정리: HTTPS의 기본 원리

  1. 클라이언트와 서버는 공개키와 CA 인증서를 통해 신뢰를 구축합니다.
  2. 인증 후 생성된 대칭키로 데이터를 안전하게 주고받습니다.
  3. 이를 통해, 제3자가 데이터를 가로채더라도 해독할 수 없게 만듭니다.

HTTPS는 완벽하지는 않지만,

오늘날 안전한 웹사이트 운영을 위한 최소한의 필수 조건으로 자리 잡았습니다.

 

 

 

출처

https://docs.tosspayments.com/resources/glossary/http-protocol

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

 

 

 

마무리 - 아 말리지마세요, 저 오늘 푸우우우욱 잘거임 ㅇㅇ.

 

데구르르를르...ㄹㄹㄹㄹ

 

컨디션이 안좋은건지 아닌건지는 모르겠지만

오늘 처음으로 가장 기본적인 내용에 대해서 말도 못하고 어버버 대는 나를 보며

어제에 이어 오늘도 현타 삠 ^-^)p

내가 제대로 못하는건가 싶기도 하고 뭐 그렇네여

그래도 뭐 엎질러진 물에

일단 그래도 남은 일정도 우다다다 남았는데 뭐..

해야.. 겠지?

오늘은 일찍 쓰고 갈거에요 그럼 20000.

 

 

 

오늘의 KPT 회고

 

Keep: 그래도 나름.. 다 했다..

Problem: 아니 가장 기본적인 내용도 말 못하는건 촘..

Try: 코드 곱씹기.

 

THE_END

728x90
반응형

'React TIL' 카테고리의 다른 글

[React] Day_52 데일리 정리  (0) 2024.12.02
[React] Day_51 개인 프로젝트 후기  (2) 2024.11.29
[React] Day_49 개인 프로젝트 중간점검  (1) 2024.11.27
[React] Day_48 데일리 정리  (0) 2024.11.26
[React] Day_47 데일리 정리  (1) 2024.11.25

관련글

티스토리툴바