지난번 글에서는 네트워크 통신의 기본인 OSI 7 Layer에 대해 알아보았습니다. OSI 7 계층 구조는 네트워크 시스템에서 각 계층이 수행하는 역할에 대한 이해를 통해 네트워크 계층 별 동작과정에 대해서 이해를 할수 있었습니다. 이번 글에서는 OSI 7 Layer 중 가장 상위에 위치한 '응용 계층(Application Layer)'에서 사용하는 대표적인 프로토콜인 HTTP와 HTTPS에 대해 알아보겠습니다. HTTP, HTTPS는 우리가 웹 브라우저로 인터넷을 탐색할 때 가장 빈번하게 사용되는 네트워크 기술로, 웹 통신의 기본과 보안을 책임지고 있습니다.
현재 저희가 방문하고, 만드는 모든 웹사이트 맨 처음에 해당 사이트 링크 앞에는 항상 https라는 이름의 글자가 붙어있습니다. ex) https://www.naver.com/ 그렇다면 모든 사이트 앞에 존재하는 이 https는 과연 무엇이고, https 전에 사용한 http와 이 둘의 차이점, https의 작동 원리 등에 대해서 전체적으로 한번 알아보도록 하겠습니다!
HTTP란?🙄
HTTP (HyperText Transfer Protocol)는 웹 브라우저와 서버 간의 데이터를 주고받기 위한 통신 규약입니다. 우리가 웹사이트를 방문할 때 주소창에 보이는 http://는 브라우저가 HTTP를 사용해 서버와 통신한다는 것을 나타냅니다. HTTP에서 클라이언트와 서버 간의 의사소통은 method라는 명령어를 통해 이루어지며, 이러한 요청에 대한 결과는 상태코드로 나타냅니다.
HTTP는 클라이언트(웹 브라우저)와 서버 간의 요청-응답 (request-response) 모델로 동작하는데, 예를들면 클라이언트 측에서 어떤걸 달라고 요청하면 서버가 그것을 보내주는 동작 원리는 지니고 있습니다.
이러한 HTTP의 주요 특징으로는 HTTP 메서드, 상태 코드가 존재하는데
HTTP는 다양한 메서드를 통해 서버에게 요청을 하는 요청방식에는
- GET: 데이터를 요청
- POST: 데이터를 전송
- PUT: 데이터를 업데이트
- DELETE: 데이터를 삭제
를 통해 서버에게 데이터 처리 방식에 대해 요청을 하고, 서버는 이러한 HTTP의 메서드를 보고 상태 코드를 통해 클라이언트의 요청에 대한 응답을 상태 코드로 나타냅니다. 대표적인 상태코드로는
- 200: 요청 성공
- 404: 요청한 리소스를 찾을 수 없음
- 500: 서버 내부 오류
등이 존재하고, 더욱 더 다양한 상태코드를 알고싶다면, HTTP 상태 코드 를 참고하면 좋을것 같습니다!
(프로젝트를 진행하다 보면 HTTP 관련 오류가 매우 빈번하게 발생하기 때문에 대표적으로 많이 발생하는 상태코드에 대한 이해가 있으면 조금 더 빠른 에러 처리가 가능할것이라고 생각합니다.)
HTTP 헤더
HTTP 헤더는 클라이언트와 서버가 요청 및 응답 과정에서 추가 정보를 교환하는 데 사용됩니다.
헤더에서 사용되는 요청 헤더와 응답 헤더는 간단하게 설명하면
- 요청(Request) 헤더: 클라이언트가 서버에 요청 시 전달
- User-Agent: 클라이언트의 브라우저 정보
- Accept: 클라이언트가 수락 가능한 데이터 형식
- 응답(Response) 헤더: 서버가 클라이언트에 응답 시 전달
- Content-Type: 응답 데이터의 형식
- Set-Cookie: 클라이언트에 쿠키 저장 요청
형식으로 되어있고, 이것도 자세하게 알아본다면 내용이 길어지기때문에 HTTP Header 정리 <= 여기에 잘 정리되어 있어서 추가적인 내용을 알고싶다면 들어가보시길 추천합니다!
그렇다면 이렇게 HTTP란 무엇이고 HTTP 메소드, 헤더에 대한 설명까진 알았는데 현대의 모든 사이트는 왜 HTTP가 아닌 HTTPS를 사용하고 있는것일까요? 이것에 대해 한번 알아봅시다!
그렇다면 HTTPS는 무엇인가?🤔
HTTPS는 HTTP에 SSL/TLS 프로토콜을 추가하여 보안을 강화한 버전입니다. 이를 통해 데이터가 암호화, 인증, 무결성을 보장받으며 전송됩니다. HTTP에 보안을 뜻하는 Secure이 붙어서 HTTPS (Hyper-Text Transfer Protocol Secure) 가 된거기 때문에 기존 HTTP보다 안전하게 사이트를 사용할수 있습니다.
그렇다면 무엇으로부터 안전한것일까요? HTTPS의 주요 기능으로는 정보 탈취 방지, 서버 신뢰성 검증이 있습니다.
HTTPS는 내가 어떤 웹사이트에 보내는 정보를 다른 누군가가 훔쳐보지 못하게 합니다.
예를 들어 설명하면 우리가 네이버에 접속해서 아이디와 비밀번호를 입력하여 로그인 버튼을 누르면 아이디, 비밀번호에 대한 정보가 인터넷을 타고 네이버의 서버로 전송됩니다. 하지만 그냥 HTTP로 보내면 이 암호가 입력한 텍스트 그대로 누구든 알아볼 수 있는 형식으로 보내지게 되는데 이것을 만약 누군가가 이 정보를 중간에 들여다본다면 쉽게 우리의 네이버 아이디와 비밀번호를 알게 되는것이죠.
(대부분 사람들은 비슷한 아이디와 비밀번호로 다른 사이트들도 이용하는 경향이 있기 때문에 하나의 개인정보만 유출당해도 매우 위험)
HTTPS는 이 정보를 네이버만 알수있는 뒤죽박죽으로 된 텍스트로 변경해서 실어보내게 되고, 이것을 다른 사람이 봐도 뭐라고 쓴건지 알아볼수가 없기에 정보 탈취 방지에 유리합니다.
두번째로는 HTTPS는 내가 접속한 웹사이트가 신뢰할 수 있는 사이트인지를 판별해줍니다.
(수상한 사이트를 걸러주고 기관으로부터 검증된 사이트만 주소에 HTTPS 사용이 허가되기 때문에 접속한 사이트가 믿을 만한 곳인지를 알려줌)
HTTP와 HTTPS의 차이점 👓
HTTP HTTPS 데이터를 암호화하지 않고 전송 SSL/TLS를 통해 데이터를 암호화하여 전송 서버 신뢰성 검증 없음 인증서를 통해 서버의 신뢰성을 보장 데이터 변조 가능 데이터 변조 방지 80번 포트 사용 443번 포트 사용
HTTPS는 보안 기능이 어떤 원리로 구현되는가?🔐
HTTPS의 보안과정을 좀 더 살펴보려면 대칭키와 비대칭키에 대한 개념을 알아야하는데
대칭키 방식에서는 상대방에게 보내고자 하는 메세지를 이 '키'와 함께 어떤 알고리즘에 넣고 돌리면 (암호화 과정) 다른 사람이 전혀 알수없는 값이 나오는데 이 대칭키 값을 넣고 아까 돌린 알고리즘을 거꾸로 실행하면 암호를 해독할수 있게됩니다. (복호화 과정) 대칭키 방식에서 키 값을 알지 못하면 절대 이 암호문을 해독할 수 없게 되는것이죠. 하지만 이 대칭키를 어떻게 양쪽이 공유할까요?
결국 한 번은 한쪽에서 다른 한 쪽으로 이 키를 전송해야 하는데 중간에 이걸 누군가 훔쳐본다면 아무런 의미가 없게 되어버립니다. 이게 대칭키의 한계이고, 이걸 보완하기위해 나온것이 비대칭 키입니다.
비대칭키 방식에서는 A,B 두 키가 있다면 A키로 암호화를 진행하면 B키로만 복호화를 할수 있는 구조로 되어있고, 이걸 반대로 B키로 암호화를 하면 A키로만 풀 수가 있습니다.
서버는 이 두 키들 중 하나는 비밀로 보관하고 다른 하나는 그냥 대중에게 공개하지만, 공개키로만으로는 암호문을 풀어낼수가 없고 개인키를 가진 서버만 풀수있는 방식으로 동작합니다.
HTTPS는 데이터 암호화에 이 대칭키와 비대칭키를 조합해 사용합니다.
간단하게 요약하자면
대칭키 암호화
- 동일한 키로 데이터를 암호화하고 복호화
- 장점: 빠르고 효율적
- 단점: 키를 전달하는 과정에서 노출될 위험이 있음
비대칭키 암호화
- 두 개의 키(공개키, 개인키)를 사용
- 공개키로 암호화된 데이터는 개인키로만 복호화할 수 있음
- 반대로, 개인키로 암호화된 데이터는 공개키로만 복호화 가능
- 서버는 개인키를 비밀로 유지하고, 공개키를 클라이언트에게 제공
비대칭키의 활용
- 클라이언트는 서버의 공개키를 사용해 데이터를 암호화
- 서버는 자신의 개인키로 이를 복호화하여 데이터를 읽어들임
- 대칭키를 안전하게 교환하기 위해 비대칭키를 사용
HTTPS가 실제로 구현되는 과정💫
HTTPS가 대칭키와 비대칭키를 조합하여 암호화를 진행할때 서버에서 사용자들에게 뿌린 공개 키가 신뢰할수 있는지 확인할수 있어야하는데 이걸 인증해주는 공인된 민간기업(Certificate Authority)들이 있습니다.
클라이언트는 서버를 아직 신뢰하지 못하기에 서버와 클라이언트는 서로를 신뢰할수 있는지에 관한 탐색과정을 거치는데, 클라이언트는 어떤 랜덤 데이터를 생성해서 서버한테 보내고 서버는 답변으로 서버측에서 생성한 무작위의 데이터와 해당 서버의 인증서를 실어보내줍니다. 이렇게 서버가 보낸 인증서가 클라이언트 측으로 오면, 클라이언트는 이 인증서를 신뢰할수 있는지 브라우저에 내장된 Certificate Authority들의 정보를 비대칭키 시스템을 통해 확인하게 되고, 해당 키로 인하여 클라이언트측에서 복호화가 가능하다면 서로 신뢰할수 있게됩니다.
이러한 HTTPS 연결을 클라이언트와 서버 간의 SSL/TLS 핸드셰이크 과정이라고 합니다!
마무리⛄
HTTPS는 보안이 중요한 모든 웹사이트에서 반드시 사용되어야 합니다. HTTPS를 통해 사용자는 안전하게 데이터를 주고받을 수 있으며, 서버는 신뢰를 유지할 수 있습니다.
이러한 HTTPS를 사용하는것만으로 모든 보안문제가 해결되지는 않지만, 오늘날 운영하는 사이트들을 HTTPS로 해놓는것은 현재 최소한의 필수 요건이 되었기에 HTTPS를 통해 사용자의 데이터를 보호하고, 서비스의 신뢰성을 높혀서 안전한 사이트를 방문, 구축하였으면 좋겠습니다!
참고:
https://developer.mozilla.org/ko/docs/Web/HTTP/Status
https://velog.io/@jkijki12/HTTP-Header-%EC%A0%95%EB%A6%AC
https://www.youtube.com/watch?v=H6lpFRpyl14
이미지 출처: https://www.elegantthemes.com/blog/wp-content/uploads/2022/01/http-https-featuredimage-1.png**
