sgcWebSockets의 네이티브 Android TLS: 배포할 OpenSSL이 없습니다

2026년 6월 11일 · 컴포넌트

Delphi 또는 C++Builder로 안전한 Android 앱을 출시하려면 항상 한 가지 추가 작업이 필요했습니다. 런타임에 OpenSSL이 존재하도록 APK에 libssl.so와 libcrypto.so를 번들로 포함하는 것입니다. sgcWebSockets는 그 작업을 없앱니다. 새로운 네이티브 TLS 백엔드 iohAndroidTLS는 암호화를 Android 자체에 넘기므로, 앱은 배포할 OpenSSL 라이브러리 없이 TLS로 연결됩니다. 이는 Enterprise 에디션에서 사용할 수 있습니다.

내부적으로 이 백엔드는 플랫폼 자체의 javax.net.ssl.SSLEngine을 JNI를 통해 구동합니다. 운영 체제가 핸드셰이크, 레코드 암호화, 인증서 검증을 수행합니다. sgcWebSockets는 평문을 넣고 암호문을 받기만 하면 되며, 이는 전체 TLS 스택이 Google이 OS와 함께 제공하고 패치하는 바로 그 스택임을 의미합니다.

전환은 한 줄

TLS 백엔드는 TLSOptions.IOHandler를 통해 선택됩니다. Android의 네이티브 TLS를 사용하려면 이를 iohAndroidTLS로 설정하세요. 네트워킹 코드의 나머지는 모두 그대로 유지됩니다.

uses
  sgcWebSocket, sgcWebSocket_Types;

WSClient.TLS := True;
WSClient.TLSOptions.IOHandler := iohAndroidTLS;
WSClient.URL := 'wss://www.esegece.com:2053';
WSClient.Active := True;

다른 플랫폼에서는 적합한 백엔드를 그대로 사용합니다. iohOpenSSL은 모든 곳에서 작동하고, iohSChannel은 Windows에서 아무것도 배포하지 않는 네이티브 옵션입니다. 작은 조건부 컴파일로 단일 클라이언트 컴포넌트를 모든 대상에서 올바르게 유지합니다.

WSClient.TLS := True;
{$IFDEF ANDROID}
WSClient.TLSOptions.IOHandler := iohAndroidTLS;   // native, no OpenSSL .so
{$ELSE}
  {$IFDEF MSWINDOWS}
WSClient.TLSOptions.IOHandler := iohSChannel;     // native on Windows
  {$ELSE}
WSClient.TLSOptions.IOHandler := iohOpenSSL;      // OpenSSL elsewhere
  {$ENDIF}
{$ENDIF}
WSClient.URL := 'wss://www.esegece.com:2053';
WSClient.Active := True;

APK에 OpenSSL 없음

이것이 핵심 이점입니다. 네이티브 백엔드를 사용하면 APK에 libssl.so와 libcrypto.so가 전혀 포함되지 않습니다. 패키지는 더 작아지고, 다시는 OpenSSL 버전을 쫓거나, 보안 권고에 맞춰 다시 빌드하거나, 라이브러리 빌드를 기기에 맞출 필요가 없습니다. TLS 구현은 기기에 존재하며 Android가 유지 관리하므로, 보안 수정 사항은 여러분의 릴리스 주기가 아니라 시스템 업데이트를 통해 도착합니다.

이는 또한 일련의 배포 문제를 제거합니다. "library not found"가 없고, 번들된 .so와 기기 간의 아키텍처 불일치가 없으며, 감사해야 할 암호화 복사본이 하나 더 있지도 않습니다. 속성 하나를 설정하고 출시하면 됩니다.

축소판이 아닌 완전한 TLS 클라이언트

네이티브 백엔드는 완전한 클라이언트입니다. Android 시스템 신뢰 저장소를 기준으로 서버를 검증하고 호스트 이름 확인을 수행하므로, 공개 인증 기관에 대한 연결은 추가 구성 없이 작동합니다. TLS 1.3을 협상하며, Android 10(API 29) 이상에서 ALPN을 지원하여 핸드셰이크 중에 http/1.1과 같은 애플리케이션 프로토콜을 광고할 수 있습니다.

다른 모든 백엔드와 동일한 TLSOptions API 뒤에 위치하기 때문에, 익숙한 속성들이 계속 작동합니다. VerifyCertificate는 피어 검증을 켜거나 끄고, RootCertFile은 비공개 기관을 신뢰하며, CertFile과 Password는 클라이언트 인증서를 제시하고, ALPNProtocols는 협상할 프로토콜을 나열합니다.

WSClient.TLS := True;
WSClient.TLSOptions.IOHandler := iohAndroidTLS;
WSClient.TLSOptions.VerifyCertificate := True;
WSClient.TLSOptions.ALPNProtocols.Add('http/1.1');  // Android 10 (API 29)+
WSClient.Host := 'your.server.com';
WSClient.Port := 443;
WSClient.Active := True;

이미 사용 중인 컴포넌트와 함께 작동

백엔드는 공유 TLSOptions에 연결되어 있으므로 WebSocket 클라이언트에 국한되지 않습니다. TCP 및 HTTP/2 클라이언트와 TLSOptions를 노출하는 다른 컴포넌트도 동일한 방식으로 이를 선택합니다. 코드가 이미 TLSOptions를 설정하고 있다면, 네이티브 Android TLS를 추가하는 것은 단일 할당이며, 연결을 열거나 보내거나 받는 방식에는 변화가 없습니다.

Apple에서도 동일한 아이디어

iOS 또는 macOS도 대상으로 한다면, 동반 백엔드 iohAppleTLS가 그곳에서 같은 일을 합니다. Apple 자체 TLS를 사용하고, 배포할 OpenSSL .dylib이 없으며, Network.framework를 통해 TLS 1.3에 도달합니다. 패턴은 동일하며, 플랫폼별로 네이티브 핸들러를 선택하기만 하면 됩니다. 자세한 내용은 Native Apple TLS 페이지에서 읽을 수 있습니다.

제공 여부

네이티브 Android TLS(iohAndroidTLS)는 sgcWebSockets의 Enterprise 에디션에 포함됩니다. 모든 플랫폼의 OpenSSL, Windows의 SChannel, 그리고 네이티브 Android 및 Apple 핸들러 등 네 가지 TLS 백엔드에 대한 전체 설명은 SSL / TLS 섹션과 Native Android TLS 페이지를 참조하세요.

sgcWebSockets 다운로드 페이지에서 다운로드하거나, GetIt 또는 등록된 계정을 통해 받으세요.

질문, 피드백, 또는 Android 앱을 OpenSSL에서 옮기는 데 도움이 필요하신가요? 문의하기, 코드를 작성한 사람들에게서 답변을 받게 됩니다.