[인증/보안] HTTPS 란? / 해싱(Hashing), 쿠키(Cookie), 세션(Session)
HTTP
: 인터넷에서 데이터를 주고 받을 수 있는 통신 프로토콜
⬇
HTTPS ? (Hyper Text Transfer Protocol Secure Socket layer)
: HTTP + Secure
: HTTP 에 보안기능(Secure) 가 추가된 것
: HTTP 프로토콜 내용을 SSL, TLS 알고리즘으로 암호화하여 보안
HTTPS 의 목적
1. 암호화
: 서버 ~ 클라이언트가 주고받는 데이터를 암호화한다.
➡ 중간에 제 3자에 의해 탈취되더라도 내용 알아볼 수 없음!
➡ 안전한 서버를 사용자가 사용하도록 유도
2. 인증서
- 데이터 제공자 신원 보장(=전자 서명) : 인증서에 작성된 도메인 = 응답객체 도메인인지? 의도한 서버임을 보장해줌
- CA (Cerfiticate Authority) : 인증서 발급해주는 공인 기관
서버의 공개키, 정보를 비밀키로 암호화하여 인증서 발급
HTTPS의 암호화
: 비대칭키 방식 + 대칭키 방식
(* 대칭키 방식 : 암호화, 복호화 모두 동일한 키 사용)
(* 비대칭키 방식 : 암호화 공개키? 복호화는 개인키. or 암호화 개인키? 복호화는 공개키.)
클라이언트 ~ 서버 데이터 주고받을 때 대칭키 사용 (비대칭키 알고리즘 = 복잡해서 컴퓨터에 부담有)
따라서 이 '대칭키' 자체를 주고 받을 때 비대칭키 방식 사용
⬇
해당 과정 풀어서 설명
서버 ➡ 클라이언트한테 인증서 보냄(전자 서명)
⬇
클라이언트 : 서버가 보낸 인증서를 검증함
클라이언트 : 검증 이후에 대칭키를 만듬 ➡ 서버의 공개키로 암호화 함
⬇
서버 : 서버의 개인키로 복호화 ➡ 내용물 확인 (클라이언트의 대칭키)
해싱 (Hashing)
: 암호화의 기본! 어떠한 문자열에 '임의의 연산'을 적용하여 다른 문자열로 변환하는 것
➡ db에 입력받은 비밀번호 그대로가 아닌 해시값을 넣으면
제 3자가 비번 탈취하더라도 위험도 낮아짐!
해싱의 철칙
1. 해시 값 계산할 때 오래 걸리지 않아야 함
2. 모든 값은 고유한 해시 값을 가져야 함
3. 아주 작은 단위의 변경이라도 완전히 다른 해시 값을 가져야 함
ex) 1234 해시값 !!!=== 12345 해시값
* 해싱된 값은 사실상 복호화가 불가능하다.
해시 알고리즘
ex) SHA1, SHA256 (많이 사용)
❗ 레인보우 테이블
: 원본 값 ~ 해시 값 대조한 값들 모두 저장된 테이블..
시간이 걸리지만 순수 해시값 만으로는 복호화해서 비밀번호 알아낼수도!
⬇
Salt 🧂
: 암호화해야 하는 값에 어떤 '별도의 값'을 추가하여 결과를 변형하는 것
: 원본 값에 약속된 '별도의 문자열' 추가해서 해시 같이 돌린다면
기존 해시값과는 다른 전혀 다른 해시값 생김! ➡ 노출되더라도 원본값 보호 가능
ex)
기존 : 비밀번호 ➡ hash 값
salt 추가 : 비밀번호 + salt ➡ hash 값
* HTTP 무상태성? : 이전까지의 응답, 요청 상태 저장을 못함..
그냥 하나의 일회성 티키타카가 전부!
🍪 쿠키 (Cookie)
: HTTP의 특징인 무상태성(Stateless)를 보완해줌!
: 서버가 일방적으로 클라이언트에 전달하는 작은 데이터
= 서버가 웹 브라우저에 정보 저장, 불러올 수 있다
해당 도메인에 쿠키 존재? http 요청시 쿠키 함께 전달 받음
ex) 사용자 선호, 테마, 로그인 상태 유지... (민감한 정보가 아닌 것들)
쿠키 옵션
: 서버가 클라이언트에 정보 저장 이후, 특정 조건 만족하는 경우에만 데이터 가져올 수 있다.
- Domain : 서버 = 요청 도메인 일치하는 경우 쿠키 전송
- Path : 서버 = 요청 세부경로 일치하는 경우 쿠키 전송
- MaxAge or Expires : 쿠키 유효기간
- HttpOnly : 스크립트 쿠키 접근 가능 여부 결정
- Secure : HTTPS 프로토콜에서만 쿠키 전송 여부 결정
- SameSite : CORS 요청의 경우 옵션, 메서드에 따라 쿠키 전송 여부 결정
1) Lax : Cross-Origin 요청? ➡ 'GET' 메소드만 쿠키 전송 가능
2) Strict : same-site 에만 쿠키 전송 가능
3) None : 항상 쿠키 전송 가능 (Secure 옵션)
*same-site : 요청 origin = 서버의 '도메인, 프로토콜, 포트'
하나라도 다르면 cross-origin임
👩🏻💻 세션 (Session)
: 사용자가 인증에 성공한 상태
브라우저가 아닌 서버에 저장하므로, 쿠키보다 안전하다. but 서버메모리 많이 차지함
이 성공한 상태(세션)을 서버가 일종의 저장소에 저장한다.
(매번 로그인 할 필요 없도록!)
세션이 만들어지면, 각 세션 구분하는 '세션 아이디' 생성됨
쿠키에 서버에서 발급한 세션 아이디 저장
🍪 쿠키 vs 👩🏻💻 세션
| 설명 | 접속상태 저장위치 | 장점 | 단점 | |
| Cookie | 쿠키는 그저 http의 stateless 를 보완해주는 도구 | 클라이언트 | 서버에 부담을 덜어줌 | 쿠키 그 자체는 인증이 아님 |
| Session | 접속 상태를 서버가 가짐(stateful) 접속 상태와 권한 부여를 위해 세션 아이디를 쿠키로 전송 |
서버 | 신뢰할 수 있는 유저인지 서버에서 확인 |
하나의 서버에서만 접속 상태를 가짐 ➡ 분산에 불리 |