dsniff 및 httpsniffing

dsniff 및 httpsniffing

명령을 실행 dsniff -i eth0하고 새 터미널 창을 열고 FTP 서버를 시도하면 연결되고 종료됩니다. dsniff는 사용자 이름과 비밀번호를 반환합니다.

google.com이나 다른 웹 서비스에서 동일한 작업을 시도하면 dsniff는 패스와 사용자 이름을 보고하지 않습니다.

왜 이런거야? 내가 사용하고 있는 웹사이트가 이러한 유형의 공격에 면역되어 있습니까? 나는 HTTP 서비스에 대해 호의적인 의견을 갖고 있지 않습니다. 내 로컬 호스트에서 사용하고 있는데 테스트 목적으로 arpspoofing이 필요하지 않다고 생각합니까?

답변1

dsniff를 사용하면 인증이 포함된 사이트를 개발할 때 통신을 암호화하기 위해 TLS를 사용해야 하는 이유를 정확히 알 수 있습니다.

암호화 계층은 "보호된" 터널 내부의 HTTP 프로토콜의 내부 작동을 실제로 난독화하며 dsniff암호화되지 않은 스트림을 얻을 수 있는 방법이 없습니다.정상적인 상황에서.

자세한 내용은 보안/스택 교환에 TLS 링크와 답변을 남겨 두겠습니다.

https://security.stackexchange.com/questions/110914/https-is-able-to-prevent-arp-poison-attack-in-lan

~에서https://en.wikipedia.org/wiki/Transport_Layer_Security

전송된 데이터를 암호화하는 데 대칭 암호화가 사용되므로 연결은 비공개입니다. 이 대칭 암호화의 키는 각 연결마다 고유하게 생성되며 세션 시작 시 협상된 비밀을 기반으로 합니다(핸드셰이크 프로토콜 참조). 서버와 클라이언트는 첫 번째 데이터 바이트를 전송하기 전에 사용할 암호화 알고리즘과 암호화 키의 세부 사항에 동의합니다(알고리즘 참조). 공유 비밀의 협상은 안전하고(공격자가 연결 중에 있어도 도청자는 협상된 비밀을 얻을 수 없음) 신뢰할 수 있습니다(공격자가 도난당하지 않는 한 협상 프로세스 중에 통신을 수정할 수 없음). 감지됨). 통신 당사자의 신원은 공개 키 암호화를 사용하여 확인할 수 있습니다. 이 인증은 선택 사항일 수 있지만 일반적으로 최소한 한 당사자(대개 서버)에서 요구합니다. 전송되는 모든 메시지에는 전송 중에 감지되지 않은 채 데이터가 손실되거나 변경되는 것을 방지하기 위해 메시지 인증 코드를 사용하는 메시지 무결성 검사가 포함되어 있으므로 연결이 안정적입니다.

관련 정보