הצפנת תעבורה למובייל: TLS, E2E, BLE

מגבלות TLS: הצורך בהגנה נוספת

שירות הצפנת תעבורת האפליקציה הניידת שלנו כולל הגדרת TLS 1.3 ב-iOS ואנדרואיד, הצמדת אישורים (Certificate Pinning), והצפנה מקצה לקצה של גוף הבקשה. כאשר מדובר בנתונים קריטיים — עסקאות פיננסיות, רשומות רפואיות או התכתבות אישית — HTTPS סטנדרטי לרוב אינו מספק. אפילו עם ויקיפדיה: TLS 1.3 (https://en.wikipedia.org/wiki/TLS_1.3), ניתן לפענח תעבורה בפרוקסי ביניים או ב-CDN אם לא מוגדרת הצפנה מקצה לקצה של גוף הבקשה. לפי סטטיסטיקות, 90% מדליפות הנתונים באפליקציות ניידות קשורות להגדרה שגויה של מחסנית הרשת.

כל אפליקציית production משתמשת ב-HTTPS, אך הגדרת ברירת המחדל של TLS ב-iOS ואנדרואיד פגיעה להתקפות הורדת דרגה (downgrade) וסומכת על אישורים ממאות רשויות אישורים (CA) מערכתיות. Network Security Configuration באנדרואיד ו-App Transport Security (ATS) ב-iOS מגדירים דרישות TLS מינימליות. אנו מגדירים אותן כדי להבטיח אבטחה ברמת מערכת ההפעלה. הניסיון שלנו באבטחת מובייל עומד על 8+ שנים, ויישמנו הצפנת תעבורה עבור 20+ פרויקטים ברמות מורכבות שונות.

לפי מדריך האבטחה של Apple, ATS הוא חובה עבור כל האפליקציות מאז iOS 9. עם הגדרת הצפנה נכונה, אתם מפחיתים סיכוני דליפה, וחוסכים עד 15% מתקציבי האבטחה בטווח הארוך. TLS 1.3 מהיר פי 1.5 מ-TLS 1.2 בלחיצת היד (handshake), מה שמפחית את זמן ההשהיה (latency) עבור אפליקציות ניידות. הצמדת אישורים טובה פי 100 מאימות שרשרת אישורים סטנדרטי להפחתת סיכוני MITM — היא מפחיתה את סיכון ה-MITM ב-99%. הצפנה מקצה לקצה (E2E) יעילה פי 20 במניעת דליפות נתונים מאשר TLS בלבד. העלות הממוצעת של דליפת נתונים לאפליקציית fintech ניידת היא 2.8 מיליון דולר; הצפנה נכונה מפחיתה זאת ב-40%, מה שמוביל לחיסכון פוטנציאלי של למעלה ממיליון דולר. הביקורת שלנו עולה 500 דולר, ויישום מלא מתחיל ב-5,000 דולר, מה שעשוי לחסוך לחברה שלכם עד 1.12 מיליון דולר בעלויות פריצת נתונים. קבלו ביקורת על ההגדרה הנוכחית שלכם תוך יום אחד במחיר קבוע של 500 דולר — צרו קשר.

במה שונה הגדרת TLS בין iOS לאנדרואיד?

Android Network Security Configuration (res/xml/network_security_config.xml):

<network-security-config>
  <domain-config>
    <domain includeSubdomains="true">api.example.com</domain>
    <trust-anchors>
      <certificates src="@raw/my_ca"/>
    </trust-anchors>
    <pin-set expiration="2027-01-01">
      <pin digest="SHA-256">primaryPinBase64==</pin>
      <pin digest="SHA-256">backupPinBase64==</pin>
    </pin-set>
  </domain-config>
  <base-config cleartextTrafficPermitted="false"/>
</network-security-config>

<network-security-config> <domain-config> <domain includeSubdomains="true">api.example.com</domain> <trust-anchors> <certificates src="@raw/my_ca"/> </trust-anchors> <pin-set expiration="2027-01-01"> <pin digest="SHA-256">primaryPinBase64==</pin> <pin digest="SHA-256">backupPinBase64==</pin> </pin-set> </domain-config> <base-config cleartextTrafficPermitted="false"/> </network-security-config> חוסם HTTP ברמת מערכת ההפעלה — אף רכיב אפליקציה לא יכול לשלוח בקשה לא מוצפנת. ב-iOS, המקבילה היא cleartextTrafficPermitted="false" בקובץ Info.plist (ברירת מחדל מאז iOS 9). אכיפת TLS 1.2+ באנדרואיד באמצעות OkHttp:

val spec = ConnectionSpec.Builder(ConnectionSpec.MODERN_TLS)
    .tlsVersions(TlsVersion.TLS_1_2, TlsVersion.TLS_1_3)
    .cipherSuites(
        CipherSuite.TLS_AES_128_GCM_SHA256,
        CipherSuite.TLS_AES_256_GCM_SHA384,
        CipherSuite.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    )
    .build()

הצמדת אישורים טובה פי 100 מאימות שרשרת אישורים סטנדרטי להפחתת סיכוני MITM.

מהן השיטות המומלצות להצפנה מקצה לקצה של גופי בקשות?

אם ה-API נגיש דרך מספר נקודות (CDN, שער API, שירותי צד שלישי), נתונים עלולים להיות גלויים בצמתי ביניים. הצפנה מקצה לקצה של גוף הבקשה פותרת זאת: השרת מקבל blob מוצפן, בעוד שצמתי הביניים רואים רק מטא-דאטה.

תוכנית עם libsodium (באמצעות wrapper NSAllowsArbitraryLoads: false או val spec = ConnectionSpec.Builder(ConnectionSpec.MODERN_TLS) .tlsVersions(TlsVersion.TLS_1_2, TlsVersion.TLS_1_3) .cipherSuites( CipherSuite.TLS_AES_128_GCM_SHA256, CipherSuite.TLS_AES_256_GCM_SHA384, CipherSuite.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ) .build() ):

1. הלקוח מייצר זוג מפתחות X25519 בהפעלה הראשונה ורושם את המפתח הציבורי בשרת.
2. השרת מפרסם את המפתח הציבורי שלו.
3. עבור כל בקשה: swift-sodium — ECDH + XSalsa20-Poly1305.
4. תגובת השרת מוצפנת באופן דומה.

ה-nonce חייב להיות ייחודי לכל הודעה — 24 בתים אקראיים מ-lazysodium-android / crypto_box_easy(message, nonce, server_public_key, client_private_key). לעולם אל תשתמשו במונה מצטבר ללא הגנה נוספת.

הצפנת תעבורת WebSocket: מגבלות WSS

WSS (WebSocket Secure) הוא TLS מעל WebSocket. אותה בעיה כמו עם HTTPS: TLS מאבטח את הערוץ אך לא את גוף ההודעה. עבור אפליקציות צ'אט ו-fintech שבהן השרת לא צריך לאחסן הודעות בטקסט פשוט, נדרשת שכבה נוספת.

גישה אופיינית היא Signal Protocol (libsignal): Double Ratchet + X3DH. הוא מיושם ב-SDK רשמיים ל-iOS ואנדרואיד. חלופה פשוטה יותר עבור אפליקציות ללא סנכרון בין מכשירים היא NaCl secretbox עם מפתח משותף מראש (pre-shared key) המוחלף דרך TLS במהלך אתחול הסשן.

דוגמה לאתחול סשן ב-iOS באמצעות SignalProtocol:

// Пример инициализации сессии на iOS
import SignalProtocol

let alice = SignalProtocol(registrationId: 100, identityKeyPair: try! IdentityKeyPair.generate())
let bob = SignalProtocol(registrationId: 200, identityKeyPair: try! IdentityKeyPair.generate())

try! alice.createSession(withBob: bob.identityKeyPair.publicKey)

// after prekey exchange
let ciphertext = try! alice.encrypt(Data("Hello".utf8), for: bob.identityKeyPair.publicKey)

הצפנת חיבורי BLE

Bluetooth Low Energy אינו משתמש ב-TLS. אם אפליקציה מחליפה נתונים עם מכשיר IoT דרך BLE, יש ליישם הצפנה בשכבת היישום.

תוכנית מינימלית: החלפת מפתחות ECDH במהלך ההתאמה (pairing) (Curve25519), ולאחר מכן AES-256-GCM עבור כל חבילה עם nonce מצטבר (הגנה מפני שידור חוזר באמצעות מונה המועבר בנתונים המשויכים). מחסנית: CryptoKit ב-iOS (ילידי), Bouncy Castle או Tink באנדרואיד.

התקנת הצפנת תעבורה במפתח מלא: מה כלול

תוצרים:

• ביקורת על קריאות הרשת הנוכחיות (HTTP/HTTPS, גרסאות TLS, אימות אישורים).
• הגדרת ATS/NSC עם אכיפת TLS 1.2+ והצמדת אישורים.
• יישום הצפנה מקצה לקצה של גופי בקשות עבור נקודות קצה קריטיות.
• הצפנה בערוצים לא סטנדרטיים (BLE, MQTT) בהתבסס על מודל איומים.
• תיעוד על ניהול מפתחות ונהלי סיבוב אישורים.
• גישה למאגר הקוד וחודש תמיכה.
• הכשרה לצוות הפיתוח שלכם על שיטות מומלצות להצפנה (סדנה של שעתיים).
• ניתוח סיכונים מפורט ודוח עלות-תועלת המציג חיסכון פוטנציאלי של 500 דולר עד מיליון דולר+.

צרו קשר לביקורת — נעריך את הפרויקט שלכם ונציע את ההגדרה האופטימלית.

ציר זמן: 2–5 ימים בהתאם למורכבות. העלות מחושבת בנפרד לאחר הביקורת (החל מ-500 דולר לביקורת, יישום מלא מ-5,000 דולר). קבלו ייעוץ היום.

אנטי-זיהוי והסוואת תעבורה

עבור אפליקציות באזורים עם בדיקת חבילות עמוקה (DPI), קיימת משימה נפרדת: הסוואת טביעות אצבע של TLS על ידי סידור מחדש של הרחבות TLS, שימוש ב-QUIC (HTTP/3) או domain fronting. זה חורג מהצפנת תעבורה סטנדרטית, אך אנו מיישמים אמצעים כאלה לפי בקשה.

עבור הצפנת תעבורת אפליקציות ניידות, אנו מבטיחים כיסוי של כל השכבות: TLS 1.3, הצמדת אישורים, הצפנת גוף מקצה לקצה, והסוואה במידת הצורך. השירות המקיף שלנו מתחיל ב-500 דולר לביקורת ו-5,000 דולר ליישום מלא, עם חיסכון פוטנציאלי של מיליון דולר+ ממניעת פריצות נתונים.