Java SSLSockets 및 반복 공격

현재 학교 프로젝트 용 Java 서버 플랫폼에서 작업 중입니다. SSL TCP 소켓을 사용하여 통신을 수행하고 있으며 클라이언트와 서버간에 JSon 프로토콜을 개발 중입니다.Java SSLSockets 및 반복 공격

제 질문은 프로토콜의 메시지가 고유 ID를 포함해야하는지 또는 SSL TCP 소켓이 반복 공격을 피할 수 있는지 여부입니다.

출처

2014-10-13 Rui Teixeira

SSL이 손상되면 "보안 통신을 강화해야합니까? 이것이 요구 사항입니다. 편집증 및 기밀 유지 수준은 어떻게됩니까? 또한 "반복 공격"은 "반복"보다 일반적인 용어입니다. 대신에이를 검색하여 더 많은 것을 배울 수 있습니다. (또한 '고유 ID 추가'는 사용자가 의도 한 바를 모른 채로 많은 것을 의미하지는 않습니다 ..) – Affe

아니요 SSL은 재생 공격에 면역이 없습니다.

출처

2014-10-13 21:42:57 EJP

-1

저는 사용자가 replay attacks을 말하고 있으며 프로토콜 구현에 따라 달라질 수 있다고 생각합니다.

동일한 메시지를 두 번받은 경우 어떻게 처리합니까?

Bob이 유효하고 합법적 인 메시지를 보내는 경우를 상상해보십시오. 귀하는 합법적 인 정당한 응답으로 응답합니다. SSL은 대화를 통해 채널을 보호하므로 아무도 네트워크 트래픽을 도청하여 원래 요청 및/또는 응답을 볼 수 없습니다.

이제 Bob의 네트워크를 위반하여 암호화 된 트래픽의 사본을 얻었을 것이라고 상상해보십시오. 암호화 된 메시지를 다시 보내면 어떻게됩니까? SSL 세션이 더 이상 유효하지 않기 때문에 SSL은 나중에 나를 보호 할 수 있습니다.

하지만 SSL 세션이 만료되기 전에 즉시 메시지를 다시 보내면 어떻게됩니까? 그때 감수성이 좋습니까?

또는 프로토콜의 일부가 토글을 발행 할 수 있습니까 (어깨 서핑이나 밥의 컴퓨터 감염) 할 수 있습니까? 어쩌면 그 토큰을 다른 곳에서 다시 사용할 수 있을까요? 그리고 제가 밥이라고 척 해줄까요? 그 때 당신의 노출은 무엇입니까?

특정 사례의 시나리오를 살펴보고 발생 위험과이를 보호하려는 노력을 조사하기 만하면됩니다.

일반적으로 SSL은 채널을 보호하지만 채널의 끝 부분이 안전하도록 프로토콜을 설계해야합니다. 프로토콜에 임의의 토큰을 포함시키고 (거기에 있는지 확인하는) 재생 공격 (CSRF 토큰)을 포함하여 여러 가지 공격으로부터 쉽게 보호 할 수 있습니다.

출처

2014-10-13 21:38:44 CoverosGene

이것은 거의 대답이 아니지만 대부분 질문이지만 최종적으로 최종 어설 션이 올바르지 않습니다. . SSL을 통한 재생에 대비하여 프로토콜을 설계 할 필요가 없습니다. – EJP

전송이 리플레이 공격의 영향을받지 않는다고해서 프로토콜이 그렇지 않다는 의미는 아닙니다. 그것은 모두 메시지를 주입하거나 재생할 수있는 위치에 따라 다릅니다. – CoverosGene

Java SSLSockets 및 반복 공격

답변

관련 문제