현재 포스트는 이후에 습득한 지식으로 인해 내용이 추가, 수정, 삭제될 수 있음
0. 🔖 목차
- 🖥️ HTTP
1-1. 개념
1-2. 메소드
1-3. 상태 코드 - 🦺 HTTPS
2-1. 개념
2-2. 안전한 사이트인지 확인
2-3. 대칭키+비대칭키 암호화
1. 🖥️ HTTP
1-1. 개념
웹 브라우저와 웹 서버 간에 데이터를 주고받을 때 사용하는 규약이다.
HTML, CSS, JS, JSON, XML, 이미지, 비디오, 폼 데이터 등의 데이터 전송을 지원한다.
용어
- URI(Uniform Resource Identifier): 어떤 자원이 어디에 위치해 있는지를 나타내는 고유한 주소. URL과 URN으로 나뉨
- URL(Uniform Resource Locator): 자원이 인터넷 상에서 실제로 어디에 위치해 있는지를 나타내는 주소(예시: http://www.example.com/index.html)
- URN (Uniform Resource Name): 자원을 위치에 구애받지 않고 이름만으로 식별하는 방법
1-2. 메소드
GET 요청
서버로부터 정보를 조회하기 위해 사용
데이터를 검색할 때 사용되며, 데이터를 서버로부터 받기만 하고 서버의 상태나 데이터를 변경하지 않음
웹 브라우저 주소창에 URL을 입력하면 브라우저는 해당 URL의 리소스를 가져오기 위해 GET 요청을 서버에 보낸다.
POST 요청
서버에 데이터를 전송하여 새로운 리소스를 생성할 때 사용
웹 폼의 데이터를 서버에 제출할 때 POST 요청이 사용
PUT 요청
지정된 URI에 대한 엔티티를 생성하거나, 이미 존재하는 경우 업데이트
주어진 리소스의 전체를 교체하는 데 사용
PATCH 요청
리소스의 부분적인 업데이트를 수행할 때 사용
PUT이 전체 리소스를 교체하는 데 사용된다면, PATCH는 리소스의 일부분만을 변경하기 위해 사용
서버에 보내는 데이터양을 줄일 수 있으며, 네트워크 효율성을 개선
DELETE 요청
지정된 URI의 리소스를 삭제할 때 사용
1-3. 상태 코드
클라이언트가 서버에게 HTTP를 통해 요청을 보내면 서버는 요청을 처리한 후 클라이언트에게 HTTP 프로토콜을 사용해서 응답을 보낸다.
이 응답에는 상태 코드가 포함되어 있다.
이 코드를 통해 클라이언트는 요청이 성공했는지, 오류가 발생했는지, 추가 조치가 필요한지 등을 알 수 있다.
-
1xx (정보 응답): 요청을 받았으며 프로세스를 계속한다는 정보
- 100 Continue는 클라이언트가 서버에 요청의 초기 부분을 보내고 나머지를 보낼지 결정하길 기다리고 있음을 나타냄 -
2xx (성공): 클라이언트의 요청이 성공적으로 받아들여졌음을 나타냄
- 200 OK는 요청이 성공적으로 처리되었음을 나타냄
- 201 Created는 요청이 성공적으로 이루어지고 새로운 리소스가 생성되었음을 나타냄 -
3xx (리다이렉션): 요청을 완료하기 위해 추가 작업이 필요함을 나타냄
- 301 Moved Permanently는 요청한 리소스가 영구적으로 새 위치로 이동했음을 나타냄
- 302 Found는 요청한 리소스가 일시적으로 다른 위치로 이동했음을 나타냄 -
4xx (클라이언트 오류): 클라이언트의 오류로 인해 요청을 수행할 수 없음을 나타냄
- 400 Bad Request는 서버가 요청을 이해하지 못했음을 나타냄
- 401 Unauthorized는 인증이 필요한 페이지나 리소스에 대한 요청을 나타냄
- 404 Not Found는 서버가 요청한 리소스를 찾을 수 없음을 나타냄 -
5xx (서버 오류): 서버가 유효한 요청을 완료하지 못했음을 나타냄
- 500 Internal Server Error는 서버 내부 오류가 발생하여 요청을 처리할 수 없음을 나타냄
- 503 Service Unavailable은 서버가 일시적으로 요청을 처리할 수 없음을 나타냄
2. 🦺 HTTPS
2-1. 개념
HTTPS는 HTTP 뒤에 붙은 S(Secure)답게 기존의 HTTP의 큰 문제점이던 보안 문제를 해결한 프로토콜이다.
HTTPS를 사용하면 이 사이트가 안전한 사이트인지 확인할 수 있고 중간에 해커가 패킷을 가로채도 데이터를 해석할 수 없다.
2-2. 안전한 사이트인지 확인
브라우저에는 자체적으로 CA 인증서 목록과 CA의 공개키가 내장되어있다.
서버는 CA에 인증받기 위해 서버의 정보(주소, 공개키 등)를 CA에 등록한다.
CA는 해당 서버에서 온 정보를 인증서 목록에 추가하고 자신의 개인키로 암호화된 인증서를 서버에게 준다.
SSL HandShake를 시작한다(TCP/IP의 3-way handshake와 별도)
클라이언트는 서버에 SSL 프로토콜로 랜덤 데이터를 전송한다.
이후 서버는 마찬가지로 SSL 프로토콜로 랜덤 데이터와 인증서를 전송한다.
클라이언트는 받은 인증서를 브라우저에 내장된 CA의 공개키로 복호화하여 인증서 정보를 확인하고 CA 인증서 목록을 확인하여 존재하면 신뢰할 수 있는 사이트로 판단하고 공개키를 가져온다.
만약 CA에 등록되지 않은 사이트가 가짜 인증서를 만들어도 이 인증서는 CA의 개인키로 암호화된 것이 아니기 때문에 복호화되어도 오류가 날 것이다.
만약 CA에 등록된 인증서를 중간에 탈취하여 자신이 CA에 인증된 사이트인 척을 해도 주소가 다르기 때문에 인증이 될 수 없다.
2-3. 대칭키+비대칭키 암호화
대칭키의 치명적인 단점은 해커가 키를 구하면 아무 의미가 없다는 것이다.
물론 해커가 이 키를 못구하게 하면 되지만 서버가 사용자와 통신하기 전 암호화를 위해 대칭키를 전송한다 했을 때 중간에 이 대칭키를 탈취할 수 있다.
HTTPS는 이를 해결하기 위해 대칭키를 비대칭키로 암호화하여 전송한다.
이렇게 암호화하면 해커에게 중간에 대칭키가 담긴 패킷을 탈취당해도 개인키를 모른다면 대칭키가 뭔지 알수가 없다.
클라이언트는 인증서로부터 통신하고자 하는 서버의 공개키를 가져온다.
이전에 SSL HandShake때 서로 주고 받았던 랜덤 데이터 2개를 이용해서 대칭키를 생성한다.
클라이언트는 이 대칭키를 서버의 공개키로 암호화하여 서버에 전송한다.
중간에 이 패킷이 탈취되어도 서버의 개인키를 모르는 해커는 내용을 알 수가 없다.
서버는 안전하게 암호화된 대칭키를 받고 자신의 개인키로 복호화하여 대칭키를 얻는다.
대칭키로 암호화를 하여 통신을 주고받는다.
