[데이터 통신] HTTP, HTTPS(SSL/TLS) 통신 이해하기 : 클라이언트-서버 통신 과정
목차
반응형
해당 글에서는 HTTP, HTTPS 통신에 대해 이해를 돕기 위해 작성한 글입니다.
1) HTTP(HyperText Transfer Protocol) 통신
💡 HTTP(HyperText Transfer Protocol) 통신
- 웹 브라우저와 서버 간에 데이터(HTML, Image, CSS, JS, JSON/XML 등)를 전송하기 위해 사용되는 프로토콜입니다.
- 클라이언트(송신 측)에서 요청을 보내면, 서버(수신 측)는 이 요청을 해석하여 적절한 응답을 클라이언트에게 반환하는 형태의 통신 방법입니다. - 대표적인 HTTP 통신을 위한 방법으로 REST API, SOAP API, GraphQL API를 이용하는 방식들이 있습니다.
- 컴퓨터 또는 네트워크 장비가 데이터를 주고받는 규칙이나 방식을 의미합니다. 이러한 프로토콜은 데이터의 전송 방식, 속도, 형식 등을 정의하며, 그로 인해 다른 컴퓨터나 장비와 원활하게 통신할 수 있습니다.
1. HTTP 통신 주요 특징
1.1. 비연결성 프로토콜(Connectionless Protocol)
💡 비연결성 프로토콜(Connectionless Protocol)
- HTTP는 상태를 유지하지 않는 비연결성 프로토콜이므로 한 번의 요청-응답을 통해 연결이 종료되면, 서버는 클라이언트와의 연결 상태를 기억하지 않습니다. - 이로 인해 서버의 부하가 줄어들지만, 이전의 요청과 그다음 요청 사이의 연결이 없어서 매 요청마다 새로운 연결이 필요합니다.
💡 아래의 그림과 같이 ‘비연결’을 확인하면 클라이언트의 요청이 수행되면 서버에서는 이를 응답하고 연결을 종료합니다.
- 클라이언트와 서버 간에 연결 상태를 계속 유지하는 통신방법을 의미합니다. 이로 인해 한 번의 연결로 여러 번의 요청-응답이 가능하며 이전 요청과 그다음 요청사이에 연결을 유지할 수 있습니다. 이로 인해 서버의 부하가 증가될 수 있습니다. - 예를 들어, 소켓 통신으로 구성한 ‘채팅 서비스’의 경우 실시간으로 서로의 데이터를 주고받으며 채팅을 해야 하기에 ‘연결성 프로토콜’을 가집니다.
1.2. 무상태 프로토콜(Stateless)
💡 무상태 프로토콜(Stateless)
- HTTP 통신에서 전송된 요청이나 응답에 대해 기억을 하지 않습니다. 즉, 클라이언트가 서버로 호출하여 전송된 데이터에 대해 유지되지 않으며, 서버는 클라이언트의 호출에 대한 응답에 대한 값이 유지되지 않습니다. - 정보를 유지하기 위해서는 쿠키나 세션과 같은 기술을 사용해야 합니다.
1.3. 요청-응답 방식
💡 요청-응답 방식
- 클라이언트의 요청(request)을 수행하면 서버는 이에 대한 응답(response)를 해주는 형태의 방식을 이용합니다. - 클라이언트는 HTTP 통신으로 자원, 행위, 표현에 대해 정의하여 서버로 요청을 수행합니다. - 서버는 클라이언트의 요청에 따라 이에 대해 클라이언트로 응답값을 전달합니다.
2. HTTP 통신 과정
💡 HTTP 통신 과정 - 해당 통신 과정은 클라이언트(Web Browser)와 서버(Server)간에 HTTP 데이터 통신을 통해 요청-응답을 하는 과정입니다.
1. 클라이언트는 서버에게 HTTP 요청을 보냅니다.
- 이 요청은 보통 URL을 통해 특정 자원을 지정하며, HTTP 메서드로 요청의 종류를 명시합니다.
2. 서버는 이 요청을 해석하여 적절한 응답을 생성하여 전달합니다.
- 이 응답은 HTTP 상태 코드로 응답의 상태를 나타내며, 필요한 경우 본문에 데이터를 담아 클라이언트에게 전달합니다.
3. 클라이언트는 서버의 응답을 받아 해석합니다.
- 웹 브라우저의 경우, HTML, CSS, JavaScript 등의 데이터를 해석하여 웹 페이지를 렌더링 합니다.
4. 위의 과정이 완료되면, HTTP의 비연결성에 따라 서버와 클라이언트의 연결은 종료됩니다.
- 다음 요청을 위해서는 새로운 연결이 필요합니다.
[ 더 알아보기 ] 💡 클라이언트가 서버로 요청을 할 때, 자원, 행위, 표현은 무엇일까?
- 자원(Resource) - 웹 상에 존재하는 데이터나 정보와 같은 모든 것을 의미하며, 이를 기반으로 Controller의 엔드포인트를 지정하게 됩니다. - 예를 들어서, 사용자의 사용자 리스트를 서비스를 호출하는 Controller가 있다고 하면 엔드포인트로 ‘api/v1/user/user’로 이름을 명명하였습니다.
- 행위(Verb) - HTTP Method를 이용한 자원에 대한 행위(조회, 생성, 수정, 삭제)를 의미합니다.
- 표현(Representation) - HTTP 통신을 수행할때 클라이언트와 서버 간의 데이터를 주고받을 형식을 의미합니다. JSON, XML, HTML 등을 통해 데이터를 주고받을 수 있습니다.
💡 [참고] Rest API 설계 방법에 대해 궁금하시면 아래의 글을 참고하시면 도움이 됩니다.
- HTTP 통신의 경우 ‘평문(Plain Text)’으로 클라이언트와 서버 간의 데이터를 주고받습니다. - 해당 과정에서 개인 정보가 노출이 되어서 보안적으로 문제가 발생할 수 있습니다.
💡 HTTP 통신의 스니핑(Sniffing)
- 스니핑(Sniffing)은 ‘코를 킁킁거리며 냄새를 맡는다’는 의미로 개가 냄새를 맡으면서 무언가를 찾으러 돌아다니는 행위에 비유가 됩니다. - 이와 같이 HTTP 통신을 수행하는 경우 HTTP 트래픽을 가르채기 위해 사용되는 기술을 의미합니다. 이 경우 HTTP 통신이 암호화되지 않은 경우 공격자가 패킷을 가로채고 읽을 수 있습니다.
- 이를 통해 공격자는 사용자의 정보를 노출시킬 수 있으며, 이는 개인정보 보호와 보안에 중요한 위협이 됩니다.
https://opentogether.tistory.com/23
2) HTTPS (HyperText Transfer Protocol Secure) 통신
💡 HTTPS (HyperText Transfer Protocol Secure) 통신
- HTTP 통신에 ‘암호화’를 추가한 프로토콜을 의미합니다. 클라이언트와 서버 사이에서 전송되는 ‘모든 데이터를 암호화’하여 중간에 데이터를 가로채더라도 내용을 알아볼 수 없게 하는 보안 기능을 갖추고 있습니다. 이로 인해 개인정보와 같은 민감한 데이터를 안전하게 보호할 수 있습니다.
- 이러한 SSL 접속은 신뢰할 수 있는 인증 기관(CA, Certificate Authority)에 의해 발행된 인증서를 통해 이루어집니다. 웹사이트가 SSL 인증서를 사용하면, 이는 웹사이트가 정당하고 신뢰할 수 있는 사이트라는 것을 사용자에게 보여주는 중요한 신호가 됩니다.
- 클라이언트와 웹 서버 간의 통신을 암호화하여 데이터가 노출되는 것을 막기 위한 보안 프로토콜을 의미합니다. 이를 통해서 클라이언트와 웹 서버 간의 안전한 연결을 만들고 이를 통해서 데이터를 안전하게 요청, 응답할 수 있습니다.
- SSL을 위해서는 SSL 인증서가 필요합니다. 이는 기업 정보와 기업이 소유한 웹 서버의 정보를 인증하고 이를 통해 사용자는 웹 사이트가 신뢰할 수 있는지 확인할 수 있습니다. - HTTPS 통신을 위해 연결하는 과정에서 3-way 핸드셰이크, SSL 핸드셰이크, 실제 수행 과정 형태로 진행이 됩니다.
1. SSL 암호화
💡 SSL 암호화
- 클라이언트와 웹 서버 간의 통신을 ‘암호화’ 하기 위한 목적으로 사용이 되는 보안 프로토콜로 SSL의 경우는 두 가지 유형의 암호화 방법을 사용합니다.
1.1. SSL 암호화: 비대칭 암호화
💡 SSL 암호화: 비대칭 암호화 - 초기 연결을 위한 핸드셰이크 과정에서 사용되며, 암호화와 복호화에 '서로 다른 키를 사용'하는 방식입니다.
- 암호화에 사용하는 공개키는 안전하게 공유될 수 있지만, 복호화에 사용하는 비밀키는 절대로 공유되어서는 안 됩니다.
💡 SSL 수행과정 요약 1. 3-Way 핸드셰이크 수행 - 클라이언트와 서버 간의 새로운 연결을 하기 위해 서로를 인지하고 ‘연결을 준비’하는 과정을 수행합니다.
2. SSL 핸드셰이크 수행
- 클라이언트와 서버 간의 통신을 ‘암호화를 위한 필요한 정보를 교환’하는 과정을 수행합니다.
3. 실제 데이터 통신 수행
- 클라이언트와 서버 간에 연결 준비와 필요한 정보를 교환하는 과정을 마치고, 통신을 위한 비밀키가 생성되어 실제 데이터를 요청하고 응답하는 통신을 수행합니다. - SSL 통신에서는 ‘SSL 인증서’를 발급받아서 암호화된 데이터를 주고받습니다.
3. SSL 수행과정 -1 : 3-WAY 핸드셰이크(HandShake) 수행
💡 SSL 암호화 수행과정-1 : 3-WAY 핸드셰이크(HandShake)
- 핸드셰이크는 사람들이 처음 만났을 때, 처음 만났을 때 손을 잡고 흔드는 악수의 행동에서 유래가 되었습니다. 악수는 일반적으로 서로의 존재를 인정하고 상호 작용을 시작하겠다는 의사 표시입니다. 이와 같이 두 컴퓨터 간의 통신을 시작하기 전에 서로를 인지하고 연결 준비를 확인하는 과정을 의미합니다. - 3-WAY 핸드셰이크의 경우에도 클라이언트와 서버 간의 새로운 연결이 맺어질 때마다 수행이 됩니다. 이를 통해 서로가 데이터를 전송하고 받을 준비가 되었음을 확인하기 위해 수행됩니다. - 이 과정은 두 디바이스 간의 통신을 동기화하는 데 필요하며, 데이터 손실이나 중복 전송 등의 문제를 방지합니다.
💡3-WAY 핸드셰이크(HandShake) 수행 예시 1. 클라이언트(Alice)가 서버(Bob)에게 SYN(동기화) 메시지를 보냅니다.
- 클라이언트(Alice)가 서버(Bob)로 연결을 시작하고자 할 때 사용되며 패킷 형태로 전달됩니다. - 해당 예시에서는 패킷으로 시퀀스번호(SequenceNum)인 x의 값을 서버(Bob)에게 전달합니다.
2. 서버(Bob)는 SYN-ACK 메시지와 함께 응답합니다.
- 서버(Bob)는 클라이언트(Alice)로부터 ‘연결 요청을 수락’하고 클라이언트-서버 간의 연결이 성립되었음을 응답합니다. - 해당 예시에서는 자체 시퀀스 번호(SequenceNum)인 y와 응답 번호(AcknowledgeNum)인 x+1을 포함하며 클라이언트로 응답합니다.
3. 클라이언트(Alice)는 응답 메시지와 함께 응답합니다.
- 클라이언트(Alice)는 서버(Bob)에게 패킷 데이터가 성공적으로 수신되었으므로 알리는 데 사용이 됩니다. - 이 메시지는 응답 번호 y+1이 포함되며 서버(Bob)가 이것을 받지만 이에 응답할 필요는 없습니다.
4. SSL 수행과정 -2 : SSL 핸드셰이크 수행
💡 SSL 수행과정 -2 : SSL 핸드셰이크 수행
- 사전에 3-Way 핸드셰이크 과정을 통해서 Client와 Server 간의 초기 연결이 확인되었고, 이후 SSL 핸드셰이크가 수행이 됩니다. - SSL 핸드셰이크의 경우는 HTTPS 연결이 설정될 때 수행이 되며, 클라이언트와 서버 간의 통신을 암호화하는데 ‘필요한 정보를 교환’합니다.
- ‘비대칭 암호화의 관점’에서는 암호화와 복호화에 사용되는 ‘서로 다른 키를 사용’하는 방식입니다. 1. 서버에서는 공개키를 가지고 있으면서, 이를 기반으로 평문을 암호화합니다. 또한 서버는 이 암호화를 풀 수 있는 ‘복호화’ 키를 가지고 있습니다. 이는 클라이언트에서 암호화한 정보를 복호화할 수 있는 키입니다. 2. 클라이언트에서는 공개키를 통해 암호화된 데이터를 복호화할 수 있는 키로 가지고 있습니다.
💡 SSL 핸드셰이크(SSL HandShake) 처리 과정 1. Client Hello : 클라이언트 → 서버 - 클라이언트는 서버에게 SSL 버전, 암호화 알고리즘 목록, 그리고 랜덤 바이트 문자열을 전송합니다. 이 정보는 서버가 클라이언트와의 안전한 연결을 설정하는 데 필요한 정보입니다.
2. Server Hello : 서버 → 클라이언트 - 서버는 클라이언트의 요청을 수락하고, SSL 버전, 암호화 알고리즘을 선택한 후, 자신의 랜덤 바이트 문자열을 클라이언트에게 보냅니다.
3. Server Certificate : 서버 → 클라이언트 (+ 공개키 포함 전송) - 서버는 이 단계에서 자신의 공개 키를 포함한 인증서를 클라이언트에게 보냅니다. 이를 통해 클라이언트는 서버의 신원을 확인할 수 있습니다.
4. Server Hello Done : 서버 → 클라이언트 - 서버가 클라이언트에게 모든 인증 메시지를 보냈음을 알리는 역할을 합니다.
5. Client Key Exchange : 클라이언트 → 서버 (+ 클라이언트에서 서버의 ‘공개키’로 암호화를 수행합니다.) - 클라이언트는 랜덤 바이트 문자열을 생성하고, 서버의 공개 키로 암호화하여 서버에게 전송합니다. 이 정보는 서버와 클라이언트가 같은 세션 키를 만드는 데 사용됩니다.
6. Client Session Key Generation( + 클라이언트에서 ‘세션키(개인키)’를 생성합니다) - 클라이언트는 앞서 생성한 랜덤 바이트 문자열과 서버의 랜덤 바이트 문자열을 사용하여 세션 키를 생성합니다.
7. Server Session Key Generation( + 서버에서 ‘세션키(개인키)’를 생성합니다.) - 서버도 마찬가지로 클라이언트의 랜덤 바이트 문자열과 자신의 랜덤 바이트 문자열을 사용하여 동일한 세션 키를 생성합니다.
8. Client Change Cipher Spec - 클라이언트는 이 단계에서 서버에게 암호화된 메시지를 전송할 준비가 되었음을 알립니다.
9. Client Finished (+ 메시지를 암호화하여 전송) - 클라이언트는 이제 변경된 암호 사양을 사용하여 메시지를 전송합니다.
10. Server Change Cipher Spec - 서버도 이제 암호화된 메시지를 전송할 준비가 되었음을 클라이언트에게 알립니다.
11. Server Finished (+ 메시지를 암호화하여 전송) - 서버는 이제 변경된 암호 사양을 사용하여 메시지를 전송합니다. 이 과정을 통해 클라이언트와 서버 사이의 안전한 연결이 완성됩니다.
5. SSL 수행과정 -3 : 실제 처리 과정
💡 HTTPS 실제 처리 과정
- 이전 단계에서 3-way Handshake에서 클라이언트와 서버 간의 연결을 확인하고, SSL Handshake에서 클라이언트와 서버 간의 암호화를 하는데 필요한 데이터 교환을 통해 비밀키 생성되었습니다. - 이를 통해 직접적으로 처리되는 과정에 대해 알아봅니다
1. 사이트 정보 제공 및 인증서 발급 요청 : 서버 → CA - 클라이언트가 서버에 접속하면 서버는 사이트의 정보와 함께 인증서 발급을 요청합니다. (서버 공개 키 + 비밀 키를 전달합니다)
2. SSL 인증서 발급 : CA → 서버 - 인증서 발급기관(CA)은 서버의 정보를 확인하고 유효한 SSL 인증서를 발급합니다.
3. 신뢰할 수 있는 서버인지 확인 요청 : 웹 브라우저 → 서버 - 클라이언트는 SSL 인증서를 받고, 인증서가 신뢰할 수 있는 CA에 의해 발급되었는지 서버로 확인을 요청합니다.
4. SSL 인증서 전달 - 서버는 SSL 인증서를 클라이언트에게 전달합니다.
5. SSL 인증서 검증 요청 - 클라이언트는 받은 SSL 인증서의 유효성을 검증하기 위해 CA에 요청을 보냅니다.
7. 서버 신뢰 - 인증서가 유효하다고 확인되면, 클라이언트는 서버를 신뢰하고 안전하게 통신을 시작합니다.
4) TLS(Transport Layer Security, 전송계층 보안)
💡 TLS(Transport Layer Security, 전송계층 보안)
- 웹사이트와 사용자 간에 전송되는 데이터를 암호화하여 인터넷 연결을 보안하는 프로토콜입니다. - 이는 데이터의 외부 공격자로부터의 보안을 제공하며, 통신이 비공개(암호화)되고 데이터가 수정되거나 손상되지 않았음을 확인합니다. 또한 사용자가 실제로 연결을 시도하는 서버와 통신하고 있음을 확인하므로, 중간자 공격을 방지합니다.
1. TLS와 SSL의 차이
💡 TLS와 SSL의 차이
- SSL(Secure Sockets Layer)는 TLS의 이전 버전입니다. 현재는 SSL 대신 TLS를 사용하고 있지만, 많은 사람들이 여전히 두 용어를 혼용해서 사용합니다.
- TLS는 SSL 3.0 버전에서 발전한 것으로, 두 프로토콜은 암호화와 인증 메커니즘에 있어서 많은 유사성을 가지고 있습니다. - 그러나 TLS는 보안 기능을 향상하기 위해 몇 가지 주요 변경 사항을 도입하였습니다. 따라서, 현재는 TLS가 더 안전하다고 간주되며, 대부분의 웹사이트는 이 프로토콜을 사용하고 있습니다.
항목
SSL(Secure Sockets Layer)
TLS(Transport Layer Security)
버전
SSL 1.0, 2.0, 3.0
TLS 1.0, 1.1, 1.2, 1.3, 1.4, 1.5
보안
SSL 3.0에서 발견된 몇 가지 중요한 보안 취약점을 포함하고 있습니다.
SSL의 보안 취약점을 해결하고, 보안 기능을 개선한 버전입니다.
속도
TLS에 비해 약간 느립니다.
SSL보다 빠른 속도를 제공합니다.
호환성
이전 웹서버와 클라이언트에서도 지원되지만, 보안 취약점으로 인해 사용이 권장되지 않습니다.
최신 웹서버와 클라이언트에서 지원되며, 보안성이 높아 권장됩니다.
암호화 알고리즘
약화된 암호화 알고리즘을 사용하는 경우가 있습니다.
더 강력한 암호화 알고리즘을 사용합니다.
2. Curl을 이용하여 TSL 처리과정 이해
💡 [참고] curl -v HTTPS 사이트 명령어를 통해서 실제 SSL 핸드셰이크 과정을 확인하실 수 있습니다.
