Delphi나 C++Builder로 빌드한 iOS 또는 macOS 앱에서 TLS를 제공하려면 예전에는 OpenSSL을 번들로 묶어야 했습니다. 즉, 직접 버전을 맞추고 패치한 libssl.dylib과 libcrypto.dylib을 앱과 함께 패키징해야 했습니다. sgcWebSockets는 이 요구 사항을 없앱니다. 새로운 네이티브 TLS 백엔드인 iohAppleTLS는 Apple 자체 TLS를 사용하므로, 배포할 OpenSSL .dylib 없이 앱이 안전하게 연결됩니다. 이 기능은 Enterprise 에디션에서 제공됩니다.
더 좋은 점은, 최신 시스템에서는 TLS 1.3을 사용할 수 있다는 것입니다. 이 백엔드는 기기에 가장 적합한 시스템 API를 자동으로 선택하며, 이 모든 것이 단일 설정 뒤에서 처리됩니다. 따라서 OS 버전에 따라 분기할 필요가 없고 코드는 어디서나 동일하게 유지됩니다.
한 줄로 전환
TLS 백엔드는 TLSOptions.IOHandler를 통해 선택됩니다. Apple의 네이티브 TLS를 사용하려면 이를 iohAppleTLS로 설정하세요. 나머지 네트워킹 코드는 변경되지 않습니다.
uses
sgcWebSocket, sgcWebSocket_Types;
WSClient.TLS := True;
WSClient.TLSOptions.IOHandler := iohAppleTLS;
WSClient.URL := 'wss://www.esegece.com:2053';
WSClient.Active := True;다른 플랫폼에서는 상황에 맞는 백엔드를 그대로 유지하면 됩니다. iohOpenSSL은 어디서나 작동하고, iohSChannel은 Windows에서 네이티브이며, iohAndroidTLS는 Android에서 아무것도 배포하지 않는 네이티브 옵션입니다. 작은 조건문 하나로 단일 클라이언트 컴포넌트를 모든 대상에서 올바르게 유지할 수 있습니다.
WSClient.TLS := True;
{$IF Defined(IOS) or Defined(MACOS)}
WSClient.TLSOptions.IOHandler := iohAppleTLS; // native, no OpenSSL .dylib
{$ELSEIF Defined(ANDROID)}
WSClient.TLSOptions.IOHandler := iohAndroidTLS; // native, no OpenSSL .so
{$ELSEIF Defined(MSWINDOWS)}
WSClient.TLSOptions.IOHandler := iohSChannel; // native on Windows
{$ELSE}
WSClient.TLSOptions.IOHandler := iohOpenSSL; // OpenSSL elsewhere
{$ENDIF}
WSClient.URL := 'wss://www.esegece.com:2053';
WSClient.Active := True;배포할 OpenSSL .dylib 없음
네이티브 백엔드를 사용하면 번들로 묶거나 버전을 맞추거나 패치할 OpenSSL이 없습니다. TLS 스택은 운영체제와 함께 제공되므로 앱이 더 가벼워지고 타사 암호화 의존성에서 자유로워집니다. App Store 제출 시에도 정당화해야 할 네이티브 라이브러리가 하나 줄어들며, TLS 정책이 몇 달 전에 고정한 라이브러리 빌드가 아니라 Apple의 정책을 따르게 됩니다. 보안 수정은 OS 업데이트를 통해 전달됩니다.
자동 폴백을 갖춘 TLS 1.3
단일 iohAppleTLS 설정이 기기별로 올바른 시스템 API를 선택합니다. macOS 10.14 이상 및 iOS 12 이상에서는 TLS 1.3을 제공하는 Network.framework를 사용합니다. 더 오래된 시스템에서는 최대 TLS 1.2까지 지원하는 Secure Transport로 폴백합니다. 어떤 버전 검사도 작성할 필요가 없으며, 백엔드가 경로를 선택하고 코드는 양쪽에서 동일합니다.
완전한 TLS 클라이언트
이것은 축소된 클라이언트가 아니라 완전한 클라이언트입니다. 시스템 신뢰 저장소를 사용하고, SNI 및 호스트 이름 검증을 수행하며, OnAppleTLSVerifyPeer 콜백을 제공하여 인증서를 직접 검사하고 수락하거나 거부할 수 있습니다. RootCertFile을 통해 사용자 지정 CA 루트로 비공개 인증 기관을 신뢰할 수 있고, CertFile과 Password로 상호 TLS를 위한 클라이언트 인증서를 제시할 수 있으며, ALPN을 통해 http/1.1 같은 애플리케이션 프로토콜을 알릴 수 있습니다.
WSClient.TLS := True;
WSClient.TLSOptions.IOHandler := iohAppleTLS;
WSClient.TLSOptions.VerifyCertificate := True;
WSClient.TLSOptions.ALPNProtocols.Add('http/1.1');
WSClient.TLSOptions.RootCertFile := ''; // optional custom CA (PEM/DER)
WSClient.TLSOptions.CertFile := ''; // optional client cert (PKCS#12) for mTLS
WSClient.TLSOptions.Password := ''; // client cert password
WSClient.OnAppleTLSVerifyPeer := DoVerifyPeer; // optional custom validation
WSClient.Host := 'your.server.com';
WSClient.Port := 443;
WSClient.Active := True;verify-peer 콜백은 인증서 주체와 그 SHA-256 지문, 신뢰 평가 결과, 그리고 연결을 허용하거나 차단하기 위해 설정하는 Accept 플래그를 제공합니다. 이곳은 인증서를 핀하거나 시스템 신뢰 결정 위에 자체 정책을 적용하기에 자연스러운 위치입니다.
이미 사용 중인 컴포넌트와 함께 작동
이 백엔드는 공유된 TLSOptions 뒤에 위치하므로 WebSocket 클라이언트에만 국한되지 않습니다. TCP 및 HTTP/2 클라이언트와 TLSOptions를 노출하는 다른 컴포넌트들도 같은 방식으로 이를 선택합니다. 코드가 이미 TLSOptions를 구성하고 있다면, 네이티브 Apple TLS를 활성화하는 것은 단일 할당이며 연결하거나 데이터를 교환하는 방식은 전혀 바뀌지 않습니다.
Android에서도 동일한 아이디어
Android도 대상으로 한다면, 동반 백엔드인 iohAndroidTLS가 그곳에서 같은 작업을 수행합니다. 즉, 플랫폼 SSLEngine을 통해 Android 자체 TLS를 사용하며 배포할 OpenSSL .so가 없습니다. 패턴은 동일하며, 플랫폼별로 네이티브 핸들러를 선택합니다. 자세한 내용은 Native Android TLS 페이지에 있습니다.
제공 범위
네이티브 Apple TLS(iohAppleTLS)는 sgcWebSockets의 Enterprise 에디션에 포함됩니다. 모든 플랫폼의 OpenSSL, Windows의 SChannel, 그리고 네이티브 Android 및 Apple 핸들러를 포함한 네 가지 TLS 백엔드에 대한 전체 내용은 SSL / TLS 섹션과 Native Apple TLS 페이지를 참조하세요.
sgcWebSockets 다운로드 페이지에서 다운로드하거나, GetIt 또는 등록된 계정을 통해 받으세요.
iOS 또는 macOS 앱을 OpenSSL에서 옮기는 데 질문, 피드백 또는 도움이 필요하신가요? 문의하기, 코드를 작성한 사람들로부터 답변을 받으실 수 있습니다.