http사이트에서 로그인을 하거나, 등등 업무를 볼 때 한번쯤 브라우저 창에서 위험할 수 있다는 경고를 받은 적이 한번 쯤은 있을 것이다. 이유는 모른 채 그런가 보다~ 하고 넘어갔는데 오늘 wireshark를 통해 http 통신을 모니터링 해보면서 왜 위험한지 배우게 되었다.
🦈 wireshark란 ?: 네트워크 간의 통신을 모니터링 해주는 도구로 오픈 소스 패킷 분석 프로그램
즉, 데이터를 주고 받을 때 데이터가 담긴 pcap(Packet Capture)이 존재하는데, 이 pcap을 확인하는 도구다.
와이어샤크를 통해 로그인 API를 HTTP 에서 요청했을 때와 HTTPS 에서 요청했을 때를 확인해 보면
HTTP로 요청했을 때에는 pcap 내 로그인한 유저의 정보(이메일, 패스워드)가 그대로 들어와서 확인을 할 수 있기 때문에 해킹의 위험이 존재한다.
반면 HTTPS로 요청했을 때에는 암호화가 되어 전달이 되기 때문에 pcap을 확인해 보아도 암호화된 문자열만 나타나지 해당 유저의 정보를 볼 수 없다.
그렇기 때문에 http에선 당연히 위험하다고 경고를 할 수 밖에!!
🦈 추가적으로 다음과 같은 상황에서 wireshark를 이용해서 네트워크 트러블슈팅을 해결할 수도 있다!
예를 들어, 서버에서 요청을 보냈는데, 프론트 쪽에선 응답을 받지 못한 상태이며, 어떤 에러가 발생하고 있는지 찾아야 하는 상황이라고 가정하자!
해당 페이지의 network를 살펴보면 pending 상태이기 때문에 요청에 대한 응답이 나타나지 않는 것을 확인할 수 있다.
하지만, 위의 network만 조회해선 pending이 발생한 정확한 원인을 파악할 수는 없다.
왜냐하면 해당 사이트로 접속이 방화벽에 막혀 있을 수도 있고, 아님 API에 대한 문제일 수도 있고 다양한 문제 원인이 존재하기 때문이다.
물론 하나하나 다 확인해볼 수는 있겠지만, wireshark를 이용하면 훨씬 수월하게 해결할 수 있다.
일단 해당 사이트의 IP주소를 확인해야 하는데, 이는 터미널에서 dig 도메인 A를 입력하면 해당 IP주소를 알 수 있다.
해당 사이트 IP 주소를 wireshark에 입력
그 후, 사이트에서 요청을 보내고 wireshark에서 확은하면, 3-way-handshake는 정상적으로 일어나는 것을 확인할 수 있다.
이 말은 곧 백엔드와의 연결에서는 문제가 발생한 것이 아니라는 것을 확인할 수 있다.
따라서 요청에 대한 처리가 늦어서 응답을 받지 못해 pending이 발생된 것으로 API 문제임을 확인해 볼 수 있다!
3-way-handshake?
TCP기반 통신을 할 때, 데이터를 전송하기 전 네트워크 연결을 설정하는 과정이다. 이는 3단계를 거친다.
1단계
SYN(synchronize): 클라이언트에서 서버에게 접속을 요청
(클:'백엔드야 나 연결해도 돼~?')2단계
SYN-ACK: 서버는 SYN 요청을 받고 클라이언트에게 요청을 수락한다는 응답을 보냄
(백:'그래 연결해도 돼~')3단계
ACK(acknowledgement): 클라이언트는 서버에게 SYN-ACK를 잘 받았다고 ACK 패킷을 보냄. 이후 연결이 이루어지고, API 요청을 통해 데이터가 오고 간다.
(클:'그럼 연결한다~')
그럼 이왕 3-way-handshake 정리한 김에 4-way-handshake도 정리하고 넘어가보자!
4-way-handshake?
이 친구도 마찬가지로 TCP 기반 통신을 할 때, 데이터 송-수신이 완료된 후, TCP 연결을 해제하는 과정이다.
1단계
FIN(finish): 클라이언트가 서버에게 연결을 종료하겠다는 패킷을 전송
(클:'이제 그것만 마무리하면 연결 종료할거야~')
2단계ACK:서버는 FIN을 받고, 확인했다고 알려주기 위해 ACK 패킷을 보낸 후, 자신의 통신이 끝날 때까지 기다림
(백:'ㅇㅋㅇㅋ 좀만 기달')
3단계FIN:서버의 통신이 끝났다면, 서버는 연결 종료에 합의한다는 의미로 클라이언트에게 FIN 패킷을 보냄
(백:'나도 이제 끝남! 이제 연결 끊어도 될 듯~?')
4단계ACK:클라이언트는 확인했다는 의미로 패킷을 보내고, 연결 종료
(클:'그래~ 연결 끊을게!')
갑자기 다른 설명으로 방향이 틀어져서 밑의 사진이 생뚱맞을 수도 있겠지만 🫠
아래의 경우는 아까 위의 문제(pending)가 발생했을 때 wireshark를 통해 통신을 모니터링한 결과이다.
이는 전부 block 상태를 나타내고 있음을 확인할 수 있다. 즉 API 접근 자체가 이루어지고 있지 않다는 것을 의미하는 것으로, 방화벽이 막혀서 등과 같은 이유로 3-way-handshake 단계까지 가지고 못한 것을 알 수 있다
이처럼 wireshark를 이용하면 네트워크 트러블 슈팅을 해결해 나갈 수 있다!!!
참고자료
: 코드캠프 강의자료
