abonglog

          • 소프트웨어 개발방법론

            • 로우파이 와이어프레임과 하이파이 와이어프레임
          • 자료구조 및 알고리즘

            • 다익스트라 알고리즘
            • 플로이드-워셜 알고리즘
            • 외판원 순회 문제(TSP) 를 완전 탐색 , DP로 풀어보자
            • 순열,조합과 그래프의 관계에 대해 알아보자
            • 백준 10986 - 나머지합 (모듈러 연산 , 누적합, 중복조합)
          • 함수형 자바스크립트

            • 모나드와 함께하는 함수형 프로그래밍 - Maybe 모나드
            • 복잡한 상태관리, 함수형으로 생각하며 리팩토링하기
            • 이터레이터와 이터러블, 제네레이터, 비동기 이터러블
            • 멀티패러다임 프로그래밍 서적 리뷰
            • 제네레이터를 이용해 자바스크립트의 큐 자료구조 10줄로 구현하기
            • 함수형 자바스크립트 모나드 알아보기
            • 함수형 자바스크립트의 펑터와 적용형 펑터
            • 커링 (currying) 에 대해 알아보자
            • 함수형 프로그래밍의 정의와 기초지식 및 가볍게 살펴보는 활용 예제
            • 함수형 자바스크립트 프로그래밍 학습 커리큘럼
          • 컴퓨터 공학 지식

            • 고급 프롬프트 엔지니어링을 위한 개념 정리
            • 개방형 와이파이에서도 폼 데이터는 안전할까 ?
          • 독서 노트

            • 솔로프리너의 시대 서평 리뷰
          • 인생 회고록

            • AI 에이전트를 이용해 블로그의 UI를 리디자인하며 느낀 회고 (바이브코딩, 양의 순환고리, 회고의 중요성)
          • 웹 브라우저 지식

            • 경험에 의거한 FSD (Feature Sliced Design) 구조 완전 공략
            • zustand는 어떻게 마법같이 동작할까?
            • 이번에 합성 컴포넌트를 이용하여 디자인 시스템을 만들어봤던 경험
            • 함수형 컴포넌트의 useEffect에 대한 사견, 부수효과 관점에서 다시 보기
            • 브라우저의 캐시 사용법 및 NextJS 에서 캐시를 사용하는 방법
            • NextJS 는 어떻게 이미지 최적화를 구현하는가 ?
          • introduction to algorithms

            • 이진 검색 트리 (이진 탐색 트리)
          • mostly-adequate-guide

            • Chapter 13: Monoids bring it all together [번역]
            • Chapter 12: Traversing the Stone [번역]
            • Chapter 11: Transform Again, Naturally [번역]
            • Chapter 10: Applicative Functors [번역]
            • Chapter 09: Monadic Onions [번역]
            • Chapter 08: Tupperware [번역]
            • Chapter 07: Hindley-Milner and Me [번역]
            • Chapter 06: Example Application [번역]
            • Chapter 05: Coding by Composing [번역]
            • Chapter 04: Currying [번역]
            • Chapter 03: Pure Happiness with Pure Functions [번역]
            • Chapter 02: First Class Functions [번역]
            • Chapter 01: What Ever Are We Doing? [번역]
          • Zero to One

            • [InklingMe : Slice-1 : Action] 첫 번째 애자일 이터레이션을 가진 후 진행한 액션 후기
            • [InklignMe : Slice-1 : Recap] 조그만 기능 대비 쓸데없이 복잡한 엔지니어링 과정을 거쳤던 과정 회고
            • 2번의 프로젝트 관리 실패로 배운 1인 개발의 씁쓸한 회고록
            • Zero to one 시리즈를 시작하며
          abonglog logoabonglog
          개방형 와이파이에서도 폼 데이터는 안전할까 ? 의 썸네일

          개방형 와이파이에서도 폼 데이터는 안전할까 ?

          컴퓨터 공학 지식
          프로필 이미지
          yonghyeun4/30/2025, 8:40:03 AM

          공부를 시작한 계기

          imageimage

          요 근래 햇살을 너무 안받고 사는거 같아서 오전엔 도서관에서 작업하곤 한다.

          현재 내 블로그는 관리자 계정으로만 사용 가능하도록 아이디와 비밀번호를 이용해 로그인 하고 있는데 비밀번호가 걸리지 않은 공용 와아파이를 이용 할 때 과연 내 아이디와 비밀번호는 보안상 안전할까 ? 라는 걱정이 들더라

          나의 얄팍한 네트워크 지식이 불안감을 키우기에 관련된 내용을 공부해보도록 한다.

          브라우저에서 서버로 데이터를 보내기까지의 여정

          일반적으로 브라우저는 HTTP (Hyper text transport protocol) 을 이용하여 데이터를 주고 받는다.

          HTTP 는 7가지 계층인 OSI (Open Systems Interconnection Reference Model) 의 통신 과정을 거친다.

          각 계층에 대한 자세한 설명은 추후 네트워크를 딥하게 공부하면서 다루도록 하고 추상적으로 어떤 일이 일어나는지 알아보자

          OIS 7 계층OIS 7 계층

          note

          7가지 계층으로 나눈 OSI 7 layer 로 표현하기도 하고 TCP/IP 프로콜의 4가지 레이어로 나눠 표현하기도 한다.

          이번 게시글에선 TCP/IP 프로토콜의 4가지 계층에 입각해 공부해본다.

          네트워크에서 전송이 일어나는 데이터 단위인 패킷은 발신지에서 애플리케이션 레이어 -> 트랜스포트 레이어 -> 인터넷 레이어 -> 네트워크 인터페이스 (링크 레이어) 과정을 거쳐 전송에 필요한 레이어 별 제어 정보를 헤더에 겹겹히 추가하여 (캡슐화) 링크 레이어를 통해 수신지로 전송된다.

          이후 수신지에선 네트워크 인터페이스 -> 인터넷 레이어 -> 트랜스포트 레이어 -> 애플리케이션 레이어 수준으로 패킷을 읽어가며 (역캡슐화) 애플리케이션 레이어에서 패킷을 읽어 처리한다.

          이런 캡슐화 과정과 역캡슐화 과정이 필요한 이유는 실제 물리적 계층들로 연결된 네트워크에서 존재하는 엣지 (수신지와 발신지) 의 주소들을 찾아 정확한 주소와 더욱 빠른 경로로 패킷을 전송(라우팅)하기 위해 필요 하기 때문이다.

          또한 계층을 나눠 코드단에선 애플리케이션 레이어단의 정보만을 처리함으로서 복잡성을 낮출 수 있다. 복잡한 전송 로직들은 다른 똑똑이 네트워크 개발자들이 개발해둔 추상화 된 프로토콜을 이용함으로서 서비스에 필요한 로직들만 처리 할 수 있다. (브라우저 단에선 단순히 보내고자 하는 주소와 데이터만 보내고 서버단에선 요청에 따른 데이터 처리만 하면 된다.)

          1. 애플리케이션 레이어 (HTTP ,FTP)

          애플리케이션 레이어는 라우팅에 직접적으로 관여하진 않고 보내고자 하는 요청에 대한 메소드와 엣지 단의 주소 정보만 입력한다.

          위 예시로 따지자면 폼 데이터에서 아이디와 비밀번호를 입력한 body 데이터와 필요한 헤더 데이터, 보내고자 하는 서버의 엔드포인트가 입력된 request 객체를 생성하는 것을 의미 한다.

          note

          문구로 된 엔드포인트의 주소를 실제 IP 주소로 변경하는 DNS 조회 과정도 애플리케이션 레이어에서 일어난다.

          2. 전송 레이어 (TCP/UDP)

          애플리케이션 레이어에서 생성된 패킷은 하위 전송 레이어에서 오류 검출 및 복구, 흐름제어와 중복 검사등을 수행하며

          양측 엣지단에서 패킷을 주고 받을 포트 번호를 이용하여 데이터를 보낸다.

          note

          오류 검출 및 복구, 흐름제어와 중복 검사는 TCP/UDP 중 어떤 프로토콜을 이용하냐에 따라 다르다.

          폼 데이터는 TCP 프로토콜을 이용하여 신뢰성 있는 패킷 전송을 보장한다.

          위 예시로 따지자면 폼 데이터가 전송 되고 폼 데이터 패킷의 크기가 물리적 계층에서 라우팅 가능한 크기보다 큰 경우 연속된 번호를 가진 패킷들로 나뉘어지고

          나뉘어진 패킷들을 순서대로 전송하며 전송 -> 전송 완료 메시지를 엣지 단에서 주고 받는다. 이 때 패킷이 유실되어 전송 완료 메시지가 오지 않은 경우엔 다시 패킷 전송을 시작한다.

          3. 인터넷 레이어 (IP)

          네트워크 도식화네트워크 도식화

          우리의 네트워크들은 엣지단에 존재하는 피시들 (클라이언트 피시와 서버 피시 등) 을 연결하는 그래프들로 이뤄져있다.

          이 때 각 엣지들은 직접적인 하나의 선으로 연결되어 있지 않다. 내가 구글을 이용한다고 해서 구글 서버와 우리집 컴퓨터만 직접적으로 연결된 하나의 선을 이용하는 것이 아니기 때문이다.

          note

          만약 그랬다면 내 노트북에는 무한개의 서버들과 연결된 무한개의 선이 존재해야 할 것이며 전 세계는 무한개의 선으로 뒤덮혀져있었을 것이다. 🫠

          실제 네트워크는 거미줄처럼 연결되어 있으며 각 거미줄 끝엔 고유한 IP 주소를 가지는 엣지단에 존재 한다.

          note

          사실 좀 더 엄밀히 말하면 고유하진 않고 NAT 를 통해 고유해지긴 하는데 그것도 나중에 딥하게 공부 할 때 서술한다.

          우선은 고유한 IP 주소가 존재한다고 생각하고 기술한다!!

          각 엣지 단까지 가는 네트워크에선 매우 많은 갈림길들이 존재하는데 각 갈림길마다 어디로 전송해야 할지에 대한 것을 결정하는 라우터가 존재 한다.

          각 라우터들은 패킷에 작성된 IP 주소를 통해 해당 IP 주소에 해당하는 엣지까지 가기 위한 다음 라우터를 찾아 패킷을 전송한다.

          4. 링크 계층 (물리적 계층)

          라우터를 통해 패킷이 이동하다가 마지막 엣지까지 도달했다면 이후엔 패킷 데이터를 물리적 매체를 통해 실제 엣지단에게 전송해야 한다.

          이 때 물리적인 매체를 이용하여 패킷을 전송하는 인터페이스를 네트워크 인터페이스 카드라고 한다.

          예를 들어 서버 컴퓨터의 경우엔 해당 포트와 연결된 물리적인 네트워크 케이블을 통해 패킷을 전송 할 것이고

          와이파이를 이용하는 브라우저의 경우엔 주파수라는 물리적 매체를 통해 와이파이와 연결된 엣지를 찾아 패킷을 전송한다.

          note

          이때 네트워크 인터페이스 카드에서 연결된 엣지를 찾을 때 사용하는 주소를 MAC 주소라 한다.

          정리

          그럼 다시 생각해보자

          내가 저 폼 데이터를 서버로 보낼 때 어떤 일이 일어날지 말이다.

          1. 클라이언트 컴퓨터는 애플리케이션 레이어에서 폼 데이터를 패킷 형태로 생성한다.
          2. 전송 레이어에서 패킷에서 보내고자 하는 IP주소와 포트번호를 식별하여 라우터에게 전송한다.
          3. 인터넷 레이어에선 IP 주소를 통해 엣지단까지 라우터를 통해 패킷을 전송한다.
          4. 링크 레이어에선 도달한 패킷을 연결된 엣지(서버컴퓨터)에게 MAC 주소를 통해 전송한다.
          5. 서버 컴퓨터는 전송받은 데이터의 IP 주소를 통해 발신지 (클라이언트 컴퓨터)를 확인한다.
          6. 전송 레이어에서 포트 번호를 확인하고 패킷 손실이 없는지 확인하고 애플리케이션 레이어로 전송한다.
          7. 애플리케이션 레이어에선 해당 포트 번호에 서버 애플리케이션에게 수신받은 패킷을 전송한다.
          note

          각 과정에서 하위 레이어에서 상위 레이어로 이동 할 때 불필요한 제어 정보는 제거한 후 패킷을 전송한다.

          생각해보자 , request , response 를 받을 때 그 안에 IP 주소나 MAC 주소 및 불필요한 기타 등등의 데이터는 존재하지 않음을 알 수 있다.

          문제점 다시 생각해보기

          그럼 생각해보자

          HTTPS 를 사용하고 있는 내 블로그에서 폼 데이터를 전송하는 것은 애플리케이션 레이어다.

          비밀번호가 없는 공용 와아파이는 링크 레이어다.

          애플리케이션 레이어에서 폼 데이터가 적절히 암호화가 일어난다면 링크 레이어에서 내 폼 데이터가 탈취 된다고 하더라도 걱정이 덜 할 것이다.

          다만 근본적으로 공용 와아파이에서 패킷을 탈취하는게 어떻게 가능한지? HTTPS 를 이용하는 레이어에선 어떤 식으로 암호화가 일어나는지 부터 다시 찾아보자

          와이파이

          와이파이와이파이

          와이파이는 어떻게 동작할까?

          와이파이는 무선랜 (WLAN, Wireless Local Area Network) 기술의 일종 으로 무선 전파수 대역을 이용하여 전자기기들이 데이터를 주고 받을 수 있도록 해준다.

          우선 무선랜 서비스를 제공하는 제공자는 무선 공유기 장치를 이용하여 네트워크의 라우터를 통해 전송받은 데이터를 와아파이 신호로 변경 하고 변경된 신호를 연결된 사용자를 식별하는 MAC 주소를 통해 사용자에게 전송한다.

          이 때 와이파이를 이용하고자 하는 사용자는 무선 랜 카드 를 가지고 있어야 하는데 무선 랜 카드를 통해 와이파이 신호를 다시 데이터 형태로 변환 하거나 역으로 변환하기 위함 이다.

          개방형 와이파이 (공용 와이파이) 의 위험성

          개방형 와이파이의 경우엔 모두가 와이파이에 접근 할 수 있으며 사용자로부터 무선 공유기까지 전송되는 데이터가 암호화가 이뤄지지 않아 데이터가 노출될 위험이 매우 높다.

          비밀번호가 존재하는 와이파이의 암호화

          무선랜 네트워크에서 사용하는 4 way handeshake무선랜 네트워크에서 사용하는 4 way handeshake

          비밀번호가 존재하는 와이파이는 비밀번호를 통해 허용된 유저만 네트워크에 접속 할 수 있게 한다는 점 외에도 데이터를 암호화 하는 프로토콜이 존재한다.

          우선 비밀번호가 존재하는 와이파이에 연결하기 위해 사용되는 비밀번호를 PSK(Pre-shared key) 라고 한다.

          클라이언트 PSK 를 이용하여 무선랜 네트워크에 연결 될 때 무선 네트워크 공유기를 의미하는 AP 와 접속하고자 하는 클라이언트는 키를 생성할 때 사용되는 Nonce 값들과 값을 메시지 무결성을 보장하는 MIC값, 사용하는 암호화 정보와 관련된 메타 정보를 주고 받는다.

          note

          Nonce 값은 키를 주고 받을 때마다 임의로 생성되는 값이다.

          note

          인증을 시행하는 AP 가 제공하는 Nonce 값은 Authenticator None 라고 하며 인증을 당하는 클라이언트가 제공하는 None 값은 Suplicant Nonce 라고 한다.

          이 단계에서 주고 받은 PSK , ANonce , SNonce 값들을 조합하여 데이터 암호화 및 복호화에 사용되는 PTK (Pairwise Transient Key) 를 생성한다.

          이후 PTK 는 무선랜 네트워크에 존재하는 세션동안 유지 되며 해당 값을 이용하여 데이터를 암호화,복호화하여 데이터를 주고 받는다.

          note

          이 과정에서 여전히 ANonce , SNonce 가 탈취되면 위험한거 아닌가? 라는 의문이 있었는데 주고받는 식별자를 나타내는 MIC 값을 교환하기 때문에 Nonce 값이 탈취된다고 해도 비교적 안전하다고 한다.

          정리

          비밀번호가 존재하는 무선랜에선 비밀번호 자체를 이용하여 무선랜 네트워크와 유저간의 암호화 키를 생성하여 클라이언트와 무선 공유기간 데이터를 주고 받을 때 데이터를 암호화 한다.

          이런 암호화 과정은 TCP/IP 4 layer 단계에서 물리적 계층에서 일어난다.

          그럼 다시 생각해보자, 예시로 들었던 폼 데이터는 개방 와이파이 환경에선 암호화 되지 않은채로 내 노트북에서 무선 공유기가 존재하는 공간에서 주파수 형태로 떠다닌단것을 의미한다. 🫠🫠

          HTTPS (TLS/SSL)

          HTTPS 프로토콜은 네트워크 계층에서 애플리케이션 레이어와 트랜스포트 레이어 사이에 보안과 관련된 Transport Layer Security 혹은 Secure Socket Layer 를 하나 더 추가한 프로토콜이다.

          해당 프로토콜을 이용하기 위해 서비스 제공자는 인증서 발급 기관인 CA(Certificate Authority) 에게 인증서를 구매하고 서비스 정보와 암호화에 사용될 공개키를 함께 제공한다.

          이후 HTTPS 프로토콜을 이용하는 서비스의 도메인에 접근 할 때 (https:// ... 로 시작하는) 다음과 같은 핸드 쉐이크 과정이 일어나게 된다.

          note

          핸드쉐이크 과정은 암호화에 사용되는 알고리즘과 프로토콜 버전에 따라 다르다.

          기본적인 설명을 위해 TLS 1.3 버전 이하에서 사용되던 RSA 알고리즘을 이용해 만들어진 핸드쉐이크 과정을 이용해 설명한다.

          TLS handshakeTLS handshake

          1. 클라이언트가 https 페이지에 진입 할 때 공유 키 생성에 사용할 클라이언트 난수와 본인이 사용 가능한 암호화 알고리즘 정보등을 서버에 전송한다.

          2. 서버는 사용 할 암호화 알고리즘과 공유 키 생성에 사용 할 서버 난수를 생성하여 공유키를 생성하고 인증서와 함께 공유키를 클라이언트에게 제공한다.

          3. 클라이언트는 해당 인증서를 CA 기관에 확인하여 CA에 등록된 서비스인지 확인한다. 클라이언트 단에서 예비 마스터키를 생성 후 이후 2번 단계에서 받은 공개키로 암호화하여 서버에 전송한다. 이 예비 마스터키는 서버에서 가지고 있는 키로만 복호화가 가능하다.

          4. 서버는 클라이언트가 전송한 키를 복호화 하여 올바른 유저인지 확인하고 1,2,3 단계에서 생성한 키들을 조합하여 세션키를 생성한다. 해당 세션키는 서버와 클라이언트 모두 대칭적으로 가지고 있다.

          5. 이후 서버와 클라이언트는 세션동안 유지되는 세션키를 이용하여 데이터를 암호화, 복호화하여 데이터를 주고 받는다.

          이렇게 세션키를 생성하고 주고받음으로서 데이터를 암호화할 수 있다.

          HTTPS 프로토콜에선 생성한 세션키를 이용해 애플리케이션레이어에서 트랜스포트 레이어로 데이터를 보낼 때 데이터를 암호화 한다. (반대로 트랜스포트 레이어에서 애플리케이션 레이어로 올 땐 복호화 한다.)

          결론

          그럼 생각해보자

          개방형 와이파이 환경에서 HTTPS 프로토콜을 이용하면 모든 데이터가 안전할까 ?

          음 .. 반은 맞고 반은 틀리다.

          애플리케이션 레이어에서 생성된 패킷은 TLS/SSL 레이어에서 암호화 되지만 그 하위 레이어의 메타 데이터들은 암호화 되지 않기 때문이다.

          암호화 되지 않는 데이터들은 애플리케이션 레이어 이하에서 생성되는 IP 주소 , MAC 주소 , 통신 관련 정보 등등 일 것이다.

          하지만 애플리케이션 레이어에서 생성된 데이터, 즉 걱정하던 폼 데이터 내부 값들은 모두 암호화 되어 전송 될 것이다.

          다행히도 내 블로그는 HTTPS 프로토콜을 이용하기 때문에 걱정하던 문제는 해결된듯 싶다 :>

          • 공부를 시작한 계기
          • 브라우저에서 서버로 데이터를 보내기까지의 여정
            • 1. 애플리케이션 레이어 (HTTP ,FTP)
            • 2. 전송 레이어 (TCP/UDP)
            • 3. 인터넷 레이어 (IP)
            • 4. 링크 계층 (물리적 계층)
          • 문제점 다시 생각해보기
          • 와이파이
            • 와이파이는 어떻게 동작할까?
            • 개방형 와이파이 (공용 와이파이) 의 위험성
            • 비밀번호가 존재하는 와이파이의 암호화
            • 정리
          • HTTPS (TLS/SSL)
          • 결론

          abonglog

          공부한 내용을 기록하고 함께 성장하고 싶어 만든 두 번째 블로그입니다.
          주로 웹개발과 관련된 내용을 포스팅합니다.

          Githubttddcc119@naver.com

          © 2026 abonglog All rights reserved.

          다음 포스트고급 프롬프트 엔지니어링을 위한 개념 정리