HTTPS 통신 방식 요약

먼저 비대칭키 암호화 방식을 사용하여 대칭키를 교환하여 안정성을 확보하고
데이터 전송을 할때에는 대칭키 암호화 방식을 이용하여 효율성을 확보

 

HTTPS 통신 방식 단계별  설명

 

1. 클라이언트가 서버에 접속

    ▷ 클라이언트가 서버에 접속하여 SSL / TLS 핸드쉐이크 시작

 

2. 서버의 인증 및 공개키 전달 

    ▷ 서버에서 CA 로 부터 받은 공개키가 포함된 인증서를 클라이언트에 전달

 

3. 키 교환 (비대칭키 암호화 방식 사용)

    ▷ 클라이언트에서 임의로 대칭키를 생성

    ▷ CA를 확인하고 얻은 공개키를 이용하여 생성한 대칭키를 암호화

 

3. 세션키 확보 (비대칭키 암호화 방식 사용)

    ▷ 클라이언트에서 암호화된 대칭키를 서버에 전달

    ▷ 서버에서 개인키를 이용하여 복호화 하여 대칭키를 획득

 

4. 데이터 전송 (대칭키 암호화 방식 사용)

    ▷ 데이터를 전송을 하는 쪽 (서버 / 클라이언트) 에서 세션키(대칭키)를 이용하여 암호화

    ▷ 데이터를 받은 쪽 (클라이언트 / 서버) 은 세션키를 이용하여 복호화

 

SSL 핸드쉐이크의 동작 과정을 나타낸 그림

"그림으로 쉽게 이해해는 웹" 에 있는 그림

 

[ 웹 ] 비대칭키(공개키)와 대칭키 비교

 

[ 웹 ] 비대칭키(공개키)와 대칭키 비교

대칭키 (Symmetric Key) 암호화 암호화와 복호화에 같은 키를 이용하는 방식 장점 단점 ◎ 빠르게 암호화 복호화 가능 ◎ 구현이 간단 ◎ 키 전달시 보안에 대한 주의 필요 ◎ 송 / 수신자 간에 동일

joey0203.tistory.com

[책][그림으로 쉽게 이해하는 웹 - HTTP- 네트워크] - 6장 : HTTP (Hypertext Transfer Protocol)

 

6장 : HTTP (Hypertext Transfer Protocol)

웹의 짝궁 HTTP 커피숍에서 주문없이 자리에만 앉아 있으면 커피는 제공되지 않는다. → 요청(주문)이 없으면 응답(커피)이 없다. Http(hypertext Transfer Protocol)?? 웹 브라우저와 웹 서버간에 데이터를

joey0203.tistory.com

 

대칭키 (Symmetric Key) 암호화

암호화와 복호화에  같은 키를 이용하는 방식

 장점  단점
빠르게 암호화 복호화 가능
구현이 간단
 키 전달시 보안에 대한 주의 필요
◎ 송 / 수신자 간에 동일한 키를 공유해야 하므로 많은 사람들과의
정보 교환 시 많은 키를 관리해야 하는 어려움

 

사용 예

▷  jwt (Json Web Tokens)

하나의 비밀키를 사용하여 토큰을 서명하고 검증 -> 토큰을 발급한 서버와 검증해야 하는 서버가 같은 비밀키를 공유해야 함
- 이때, HMAC (Hash-based Message Authentication Code) 이용하여 구현된 알고리즘 HS256, HS384, HS512 을 사용.

 

세션 쿠키 암호화

웹 애플리케이션에서 사용자가 로그인할 때 서버는 사용자의 세션 ID를 생성하고 이를 대칭키를 사용하여 암호화하여 쿠키에 저장

 

이외에도

    - 모바일 장치에 액세스 :  비밀번호, 패턴, 지문 인식 등을 사용하여 데이터를 암호화 복호화

    - 컴퓨터나 모바일 장치 : 개인 파일이나 중요한 문서를 암호화할 때 대칭키 암호화(비밀번호)

    - 온라인거래 / ATM 거래:   사용자의 금융 정보, 개인 정보, 거래 세부정보 를 암호화

 

비대칭키 (Asymmetric Key) 암호화

암호화 복호화 할때 다른 키( 공개키, 개인키)를 이용하는 방식, 공개키 암호화라고도 함

 장점  단점
여러 송신자가 하나의 공개키로 암호화를 수행하기 때문에
사용자가 많더라도 키를 관리하는 데에 유리
복잡한 수학 연산을 사용하기 때문에, 대칭키 암호에 비해 효율성이 떨어질 수 있음

 

암호화 및 복호화 하는 방식 

  ① 송신자는 수신자의 공개키를 획득

 송신자는 수신자의 공개키로 데이터를 암호화

 송신자는 암호화된 데이터를 수신자에게 전달

 수신자는 자신의 비밀키(개인키)로 암호화된 메세지를 해독(복호화)하여 데이터를 확인

 

사용 예

▷ 전자 서명(Digital Signature)

 공개키 암호를 거꾸로 활용하는 방식,
 송·수신자의 역할이 반대로 되어, 개인키를 소유한 사람만이 전자 서명 알고리즘을 통해 *평문에 대한 서명 값을 생성가능
 생성된 서명 값에 대하여 공개키를 이용하면 평문을 검증할 수 있기 때문에, 누구나 그 서명을 검증할 수 있게 되는 방식

  *평문 (plain text) : 암호학에서 평문은 암호 알고리즘의 입력 대상으로 예정이 된 암호화되지 않은 정보를 의미

   - 소프트웨어가 변조되지 않았으며 특정 개발자에 의해 생성되었음을 보증할 때도 사용

 

HTTPS 로 통신시 SSL/TLS 인증서를 사용하는 과정

  웹 서버와 클라이언트 간의 안전한 통신을 보장하기 위해 SSL/TLS 인증서가 사용되는 과정에서 비대칭키 암호화 방식을 적용
      (인증서 제공) 서버가 웹 서버는 SSL/TLS 인증서와 함께 공개 키를 클라이언트에게 제공

       (인증서 검증) 클라이언트가 인증서에서 공개키 획득

      (대칭키 생성) 클라이언트가 무작위로 대칭키를 생성 공개키를 이용하여 암호화

      (대칭키 암호화 및 전송) 공개키를 이용하여 암호화 한 후, 암호화된 대칭키를 서버에 전송

      (대칭키 복호화)서버에서 개인키를 이용하여 복호화하여 대칭키 획득

      ⑥ (세션 쿠키 암호화) 이 키를 사용하여 통신 과정에서 데이터를 안전하게 암호화하고 복호화

           - 이 부분은 대칭키 암호화 방식

 

메시지 암호화

    발신자는 수신자의 공개 키로 메시지를 암호화하고, 수신자는 자신의 개인 키로 이를 복호화하는 방식

    메세지가 전송되는 과정에서 읽히거난 변경되는 것을 방지 : 웹 기반 이메일이나 메시징 앱에서 사용

 

jwt 비대칭키 방식 (RS256, RS384, RS512, ES256)

   토큰 발급자는 개인 키를 보유하고 비밀로 유지하며, 수신자는 공개 키를 사용하여 토큰의 서명을 검증가능

 

참고자료

https://raonctf.com/essential/study/web/asymmetric_key

 

RAON CTF - WEB Essential

DES 암호화 AES 암호화 양방향 암호, 대칭키 암호

raonctf.com

https://lesstif.gitbook.io/web-service-hardening/encryption

 

대칭키 암호화 | web service hardening

대칭키(Symmetric key) 방식은 암호문을 생성(암호화)할 때 사용하는 키와 암호문으로부터 평문을 복원(복호화)할 때 사용하는 키가 동일한 암호 시스템으로 일반적으로 알고 있는 암호 시스템입니

lesstif.gitbook.io

 

https://ko.wikipedia.org/wiki/%ED%8F%89%EB%AC%B8

 

평문 - 위키백과, 우리 모두의 백과사전

위키백과, 우리 모두의 백과사전. 시호 평문(平文)에 대해서는 탁발울률 문서를 참고하십시오. 암호학에서 평문(平文)은 암호 알고리즘(보통은 암호화 알고리즘)의 입력 대상으로 예정이 된 암

ko.wikipedia.org

https://seed.kisa.or.kr/kisa/intro/EgovDefinition.do

 

 

정의

클라이언트를 대신해서 내부 서버로 요청을 전달해주는 서버 

 

역할

- 보안 강화 : SSL(Secure Socket Layer) 사용

ex) nginx 를 이용하여 인증기관으로 부터 발급받은 SSL 인증서를 적용가능하게 된다. -> HTTPS 프로토콜 사용 가능

 

- 과부하 방지

로드 밸런싱(load balancing)을 이용하여 트래픽을 균등하게 배포

 

#로드 밸런싱(load balancing)

(이점)

- 애플리케이션 가용성 :

    서버장애를 감지하여  트래픽을 사용가능한 서버로 분배하여 시스템의 내결함성을 높일 수 있음

           *내결함성 = 시스템이 장애또는 고장에도 계속해서 정상적으로 동작이 가능하도록하는 능력

- 애플리케이션 확장성 :

      한 서버에서 병목 현상 방지,
      필요한 경우 서버의 수를 조정할 수 있도록 트래픽을 예측함

- 애플리케이션 보안 :
    공격자가 일으키는 수백만개의 동시 요청을 우회및 차단하여 영향을 최소화할 수 있음  

- 애플리케이션 성능

    응답 시간을 늘리고 네트워크 지연 시간을 줄여 애플리케이션 성능을 향상 시킴

 

사용하는 이유/ 필요성

  • 로드밸런싱 : 서버 트래픽 분산
    • 하루에도 수백만명이 방문하는 웹 사이트에서 발생하는 대량의 트래픽을 감당하기 위해 사용된다. 즉, 웹 서버들 앞에 리버스 프록시 서버를 두어서 특정 서버가 과부하가 되지 않게 밸런싱을 맞추는 것이 가능하도록 한다.
  • 보안 강화
    • 클라이언트의 요청은 먼저 리버시 프록시를 거쳐서 서버로 전달 되므로, 이때 악성 요청을 필터링가능
  • 캐싱 및 가속화
    • 자주 사용되는 정적 파일들을 캐시에 저장하여 빠르게 제공

 

 

 

참고자료

https://losskatsu.github.io/it-infra/reverse-proxy/#2-%ED%8F%AC%EC%9B%8C%EB%93%9C-%ED%94%84%EB%A1%9D%EC%8B%9Cforward-%EC%84%9C%EB%B2%84%EB%9E%80

 

[Infra] 리버스 프록시(reverse proxy) 서버 개념

리버스 프록시(reverse proxy) 서버 개념

losskatsu.github.io

https://narup.tistory.com/238

 

[Nginx] 리버스 프록시(Reverse Proxy) 개념 및 사용법

1. 개요 리버스 프록시란? 클라이언트 요청을 대신 받아 내부 서버로 전달해주는 것을 리버스 프록시(Reverse Proxy) 라고 합니다. 저도 사실 프록시라는 개념이 낯설었는데요, 일단 프록시라는 개념

narup.tistory.com

https://aws.amazon.com/ko/what-is/load-balancing/

 

로드 밸런싱이란 무엇인가요? - 로드 밸런싱 알고리즘 설명 - AWS

로드 밸런싱은 애플리케이션을 지원하는 리소스 풀 전체에 네트워크 트래픽을 균등하게 배포하는 방법입니다. 최신 애플리케이션은 수백만 명의 사용자를 동시에 처리하고 정확한 텍스트, 비

aws.amazon.com

 

정적 콘텐츠 : 미리 생성되어 저장된 것을 사용자의 요청에 따라 변경하지 않고 제공되는 콘텐츠

동적 콘텐츠 : 사용자의 요청에 따라 서버에서 생성되어 제공되는 콘텐츠

정적 콘텐츠 동적 콘텐츠
미리 생성되어 저장된 콘텐츠 사용자의 요청에 따라 서버에서 생성되어 제공되는 콘텐츠
모든 사용자에게 동일한 내용 제공 사용자에 따라 다른 내용 제공 가능
서버 측에서 별도의 데이터 처리나 로직실행이 필요 없음 서버 측에서 데이터 처리와 로직실행 등의 작업이 필요
HTML, CSS, 이미지, 비디오 장바구니에 담긴 내용, 사용자의 사용 패턴에 따라 개인화된 페이지

+ Recent posts