HTTPS
Hyper Text Transfer Protocol Secure socket layer(HTTPS)는
HTTP over SSL(TLS), HTTP over Secure라고도 불리며, 통상적인 HTTP 요청을 SSL 혹은 TLS
라는 알고리즘을 통하여 HTTP가 통신하는 과정에서 데이터를 암호화하여 전송하는 방법이다.
HTTP + SSL
주목적으로는 '암호화'에 있다.
데이터가 암호화되어 전송되기 때문에 정확한 Key로 decoding 하기 전 까지는 내용을 알 수 없다.
HTTPS는 암호화를 위해 [대칭 / 비대칭 키 알고리즘]을 사용한다.
handshaking 과정에서 [비 대칭키]를 사용하여 인증서에 [대칭 키]를 보내고 해당 인증서에서 대칭키를
안전하게 확인하였다면 그 이후로는 대칭 키를 사용하여 전달한다.
Https는 공개키? 대칭키? 비대칭키?
공개키와 비대칭키를 혼용해서 쓰는 걸로 알고 있고 두 개 다 같은 말이라고 생각하고 글을 쓰겠다. Https 관련 글들을 보면 공개키를 통해 평문을 암호화 복호화한다고 되어있고 어느 글들은 공
100100e.tistory.com
공개키(비대칭 키)로 암호화된 정보는
개인이 갖고 있는 비밀 키로만 복호화 가능하기 때문에 중간에 대칭 키가 털리더라도
개인키가 없으면 복호화할 수 없다.
대칭키 암호화 - 양방향
* 키 한개로 암복호
비대칭키 - 양방향
* 암호 / 복호 키가 다름
* 개인키로 암호, 공개키로 복호= 전자서명
* 공개키로 암호, 개인키로 복호 = 암호화
해시 - 단반향
* 시드 + 본문의 해시값이 같은지 확인
인증서
HTTPS의 다른 특징 중 하나는 브라우저가 서버의 응답과 같이 전달된 인증서를 확인 가능한 점이다.
이러한 인증서는 서버의 신원을 보증하는 역할을 한다.
이때 이렇게 신원을 보증할 수 있는 제 3자를 이용하는데 이를 Certificate Authority, CA라고 한다.
CA는 인증서를 발급해주는 공인된 기간을 말하는데, 서버의 공개키와 CA의 비밀키로 암호화하여
인증서를 발급한다.
서버가 클라이언트에게 CA에서 발급받은 인증서를 전달하면, 클라이언트는 OS 또는 브라우저에 미리
내장된 CA리스트를 통화 인증된 곳에서 받은 인증서인지 판별하고, 만약 아니라면 서버와의 연결이
안전하지 않다는 경고창을 띄운다.
따라서 클라이언트 측(브라우저)은 인증서의 도메인과 데이터를 제공하는 서버의 도메인을 비교할 수
있으므로 중간자 공격을 방지할 수 있다.
이런 식으로 서버 - 클라이언트 간의 CA를 통해 서버를 인증 / 데이터 암호화하는 과정을 나타내는
프로토콜을 TLS 또는 SSL이라고 한다. (사실상 동일함: SSL이 표준화된 이름이 TLS)
Hash
문자열에 임의의 연산 알고리즘을 적용하여 다른 문자열로 변환하는 것
Hashing을 사용하기 전제 조건은 다음과 같다.
* 모든 값에 대한 Hash값을 만들 때 오래 걸리면 안 된다.
* 최대한 Hash값을 피해야 하며, 모든 값은 고유한 Hash값을 갖는다.
* 아주 작은 단위의 변경이라도 전혀 다른 Hash값을 가져야 한다.
대표적인 Hash 알고리즘으로는 SHA1 / SHA256이 있다. SHA256을 많이 사용한다.
Salt
특정 알고리즘을 통한 Hash값은 항상 결과가 같기 때문에 Rainbow Table같이 모든 원본 값과
Hash값을 정리해놓은 테이블을 사용한다면 쉽게 원본 비밀번호를 알아낼 수 있는 여지가 있다.
'JohnTheRipper', 'HashCat' 같은 Hash값 탈취를 위한 도구들도 존재한다.
이를 보완하기 위해서 Salt라는 것을 사용하는데, Salt는 기존 문자열에 특정 Salt값을 추가하여
Hashing 한다. 이렇게 하면 사용된 알고리즘이 노출되더라도 원본 데이터를 보호할 수 있다.
[기존 방법]
(Password) ------------> (Hash값)
[Salt 사용]
(Password) + (Salt값) ------------> (Hash값)
Salt 사용 시의 주의사항은 다음과 같다.
* Salt는 User와 Password별로 유일한 값을 가져야 한다.
* 사용자 계정을 생성할 때와 비밀번호를 변경할 때마다 새로운 임의의 Salt를 사용하여 해싱해야 한다.
* Salt는 1회용이다
* Salt는 DB의 유저 테이블에 같이 저장되어야 한다.
HTTP Cookie
서버가 클라이언트 (웹 브라우저)에 저장해놓는 정보
장기간 저장해야 하는 정보를 클라이언트에 저장하기에 적합하다. [장바구니, 로그인 정보, 테마 등]
HTTP자체로는 '무상태성 - Stateless'의 성격이 있으므로 쿠키를 통해 상태 정보를 기억할 수 있다.
쿠키를 이용하는 것은 단순이 서버에서 클라이언트에 쿠키를 전송하는 것뿐만 아니라
클라이언트에서 서버로 쿠키를 전송하는 것도 포함한다. 클라이언트에서 서버로 쿠키를 보낼 때는
특정 조건이 만족하는 경우에만 가능한데, 이를 '쿠키 옵션'을 통해 설정 가능하다.
| 쿠키 옵션 | |
| Domain | www.google.com 처럼 서버에 접속할 수 있는 이름이다. 포트 / 서브도메인 정보 / 세부경로 포함 X (예: google.com) |
| Path | 서버가 라우팅 할 때 사용하는 세부 경로 http://localhost:8080/users/login 일때, path는 /users/login이 된다. (기본값 / ) |
| MaxAge / Expires | 쿠키가 유효한 기간을 정하는 옵션 MaxAge- 초단위 / Expires - Date단위 이 옵션에 따라 Session Cookie(세션 - 브라우저 종료시 쿠키 삭제)와 Persistent Cookie(영속성 - 유효기간 만큼 쿠키 존재) 로 나뉜다. |
| Secure | 쿠키를 전송해야 할 때 사용 프로토콜에 따른 쿠키전송 여부 설정 True - https프로토콜을 사용해서 통신을 하는 경우에만 쿠키 전송 가능 Secure옵션이 없으면 프로토콜 상관 없이 http나 https 모두에게 쿠키 전송 가능 |
| HttpOnly | JavaScript에서 브라우저의 쿠키 접근 여부 결정 true - Js접근 불가 false(기본값) - Js접근 가능 (XSS공격에 취약) |
| SameSite | Cross-Origin 요청을 받은 경우, 요청에 사용된 메서드와 해당 옵션(GET,POST,PUT..) 의 조합으로 서버의 쿠키 전송 여부를 결정 [사용 가능 옵션] * Lax: Cross-Origin요청이면 GET메서드에 대해서만 쿠키 전송 가능 * Strict: Cross-Origin이 아닌 same-site인 경우에만 쿠키 전송 가능 * None: 항상 쿠키 전송 가능 (다만 Secure 옵션이 필요하다) |
same-site
요청을 보낸 Origin과 서버의 도메인, 프로토콜, 포트가 같은 경우. 하나라도 다르다면 Cross-Origin이다.
이런 옵션들을 지정해서 클라이언트 측에 쿠키를 처음 전송하게 되면 헤더에 Set-Cookie라는 프로퍼티에
쿠키를 담아 쿠키를 전송한다.
이후에는 Cookie라는 프로퍼티에 쿠키를 담아 쿠키를 전송한다.
쿠키를 통한 상태 유지
이런 쿠키의 특성을 통해서 장바구니, 로그인 유지 같은 Stateful 한 인터넷 연결을 사용할 수 있다.
그렇지만 기본적으로 쿠키는 오랫동안 유지될 수 있고, JS 같은 스크립트 등을 통해 쿠키에 접근이
가능하기 때문에, 개인정보 같이 민감한 정보를 쿠키에 담는 것은 위험하다.
Set-Cookie - HTTP | MDN
The Set-Cookie HTTP response header is used to send a cookie from the server to the user agent, so that the user agent can send it back to the server later. To send multiple cookies, multiple Set-Cookie headers should be sent in the same response.
developer.mozilla.org
Session
서버가 클라이언트에 유일하고 암호화된 ID를 부여
중요 데이터는 서버에서 관리
사용자가 인증에 성공한 상태를 'Session'이라고 부른다. 그리고 이 세션을 서버에서는 일종의
저장소에 따로 저장하는데, 주로 in-memory 또는 세션 스토어(Transaction이 빠른 DB - redis처럼)
같은 저장소를 사용한다.
[로그인]
정확한 ID와 PW를 사용해 로그인에 성공하면, 서버는 인증에 성공했다고 인지를 하고,
인증의 성공한 상태인 세션을 생성한다.
세션이 생성되면, 각 세션을 구분하도록 세션 아이디도 생성되는데 보통 클라이언트에 세션 성공을
증명하기 위한 수단으로 세션 아이디를 사용한다.
이때, 웹 사이트에서 로그인을 유지하기 위한 수단으로 Cookie가 사용된다.
쿠키에는 서버에서 발급한 세션 아이디를 저장한다.
[로그아웃]
세션 아이디가 담긴 쿠키는 클라이언트 측에 저장되어 있고, 서버는 세션을 저장하고 있다.
서버는 단지 세션 아이디로만 인증 여부를 판단하게 되는데, 이 부분이 공공장소에서 로그아웃을
생활화해야 하는 이유이다.
즉 로그아웃 하기 위해서는 다음의 2가지 작업을 수행해야 한다.
[서버 측]: 세션 정보를 삭제해야 한다.
[클라이언트 측]: 쿠키를 갱신해야 한다.
여기서 서버가 클라이언트의 쿠키를 임의대로 삭제할 수 없으므로, set-cookie를 통해 클라이언트에게
쿠키를 전송할 때 세션 아이디의 키 값을 무효한 값으로 갱신 가능하다.
Cookie & Session
| 설명 | 접속 상태 경로 | 장점 | 단점 | |
| Cookie | 쿠키는 그저 http의 stateless한 것을 보완한다 |
Client | 서버에 부담을 덜어준다 | 쿠키 자체로는 인증 수단이 될 수 없다 |
| Session | 접속 상태를 서버가 갖는다 [stateful] 접속 상태와 권한 부여를 위해 세션ID를 쿠키로 전송 |
Server | 신뢰 가능한 유저인지 서버에서 추가로 확인 가능 |
하나의 서버에서만 접속 상태를 갖는다. 분산에 불리하다 |
대립 구도라기보다 상호 보완의 느낌이 큰 것 같다.
'web > NETWORK' 카테고리의 다른 글
| HTTP (0) | 2022.08.10 |
|---|---|
| 브라우저의 작동 원리 (0) | 2022.06.07 |