카테고리 없음

[인코그니토 2주차]

jwk818 2024. 1. 19. 17:37

<실습 환경 설치>

 

실습 1을 위한 spring 툴을 설치하기 위해 openjdk 11버전을 설치해준다. 

 

 

이클립스에서 계속 오류가 났던 이유가 jdk 버전을 17로 해서 너무 높아서 그런 것 같다.

 

 

sts4 설치 완료

 

 

 

계속 오류가 났던 원인이 preferences > compiler에서 jdk 버전이 17로 되어있어서 그런 것 같다. 우선 아까 설치한 openjdk-11 버전에 맞춰 11로 바꿨다.

 

 

인코딩 텍스트 값도 UTF-8로 바꿨다. 

 

 

JAVA와의 충돌 방지를 위해 Gradle에 경로를 입력해주고 밑에 automatic project synchronization을 눌러준다. 여기까지 하면 스프링 설치가 끝났다. 이제 프로젝트 생성을 통해 우리가 원하는 웹소켓 양방향 통신 실습에 들어간다. 

 

 

 

 

<실습>

 

 

 

 

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.Configuration;

@SpringBootApplication
@Configuration
public class ChattingApplication {

	public static void main(String[] args) {
		SpringApplication.run(ChattingApplication.class, args);
	}

}

 

 

 

 

이제 client jsp 페이지를 만든다.

아까 만들어뒀던 WEB-INF > jsp > chat.jsp 파일을 만들어 코드를 입력했다. 

 

 

 

메인 컨트롤러를 만들어준다. 

 

 

 

그리고 ChattingApplication.java를 Spring Boot App을 이용하여 실행한다.

 

그리고 localhost:8080에 접속하면 채팅방을 확인할 수 있다. 만약 두 개의 접속 페이지를 만든다면 서로 통신하는 채팅방 페이지가 된다. 

 

 

 

 

 

 

채팅 프로그램이 잘 구현된 것을 확인했고, Wireshark를 이용해 패킷 분석을 시도했다. 

 

전체 패킷 분석 내용 중 보기 쉽게 websocket으로 필터링을 걸어준다.

 

 

 

 

 

이렇게 프레임에 입력했던 텍스트가 그대로 뜨는 것을 확인할 수 있다. 만약 데이터를 보낼 때 암호화하지 않고 보내면 위와 같이 데이터가 frame에 그대로 노출되어 기밀성 취약점이 생긴다. 그리고 데이터가 노출뿐만 아니라 변조 여부 역시 확인할 수 없어 무결성 취약점이 발생한다.

 

기본적으로 웹소켓은 암호화를 제공하지 않아, 암호화하지 않은 평문 데이터를 보내면 중간자 공격에 취약해져 기밀성 취약점이 발생하고 통신 내용이 노출될 수 있다. 또, 웹소켓 연결 시 클라이언트 서버 등의 인증이 부재하면 중간자 공격자가 통신에 참여하여 기밀성과 무결성을 침해할 수 있다. 그리고 별도의 데이터 위변조 여부 확인을 하지 않으면 데이터가 중간에 변경될 수 있고, 이 역시 무결성 취약점으로 이어진다.

 

이를 해결하기위해 HTTPS를 통한 웹소켓 연결 설정으로 통신 암호화, TLS/SSL 사용, 상호 인증 등의 방법으로 데이터를 안전하게 전송할 수 있다. 

 

 

 

  1. TLS 핸드셰이크 (TLS Handshake): 클라이언트가 서버에게 연결을 요청하면, 서버는 TLS 핸드셰이크를 시작한다.  클라이언트와 서버 간에 통신에 사용할 암호화 알고리즘 및 키를 설정한다.
  2. 서버 인증 (Server Authentication): 서버는 클라이언트에게 공인된 CA(Certificate Authority)에 의해 서명된 디지털 인증서를 제공한다. 이 인증서에는 서버의 공개키와 서버의 정보가 포함되어 있고, 클라이언트는 이 디지털 인증서를 검증하여 서버의 신원을 확인한다. 
  3. 클라이언트 인증 (Optional): 서버가 클라이언트로부터의 인증을 필요로 하는 경우, 클라이언트도 인증서를 제공한다. 이를 통해 서버는 클라이언트의 신원을 확인할 수 있다. 
  4. 세션 키 교환 (Key Exchange): 클라이언트와 서버는 핸드셰이크를 통해 공유 비밀키(세션 키)를 생성합니다. 이 공유 비밀키는 통신 데이터를 암호화하고 복호화하는 데 사용된다. 다양한 키 교환 알고리즘 중에서는 주로 Ephemeral Diffie-Hellman(ECDHE 또는 DHE) 알고리즘이 사용된다. 
  5. 암호화된 통신 (Encrypted Communication): 핸드셰이크가 완료되면 클라이언트와 서버 간 전송되는 모든 데이터는 암호화 된다. 이때 사용되는 알고리즘은 핸드셰이크 단계에서 협상된 대칭 암호화 알고리즘입니다. 이제 암호화된 연결을 통해 클라이언트와 서버 간의 웹소켓 데이터가 안전하게 전송된다. 
  6. 무결성 검증 (Integrity Verification): 암호화된 데이터는 무결성 검증을 위해 MAC(Message Authentication Code) 또는 해시 함수를 사용하여 서명되고, 이를 통해 전송 중 데이터의 변조 여부를 확인한다.