לוגו אתר Fresh          
 
 
  אפשרות תפריט  ראשי     אפשרות תפריט  צ'אט     אפשרות תפריט  מבזקים     אפשרות תפריט  צור קשר     חץ שמאלה חץ ימינה  

לך אחורה   לובי הפורומים > מחשבים > חומרה ורשתות
שמור לעצמך קישור לדף זה באתרי שמירת קישורים חברתיים
תגובה
 
כלי אשכול חפש באשכול זה



  #1  
ישן 24-04-2017, 17:00
צלמית המשתמש של Musicman0
  משתמש זכר Musicman0 Musicman0 אינו מחובר  
 
חבר מתאריך: 25.12.05
הודעות: 5,004
SSL TLS Handshake

אני בפורום המתאים?

יש לי עבודה לעשות וקצת הלכתי לאיבוד ואשמח לכמה חלקים בפאזל שחסרים לי.
קראתי פה:
https://msdn.microsoft.com/he-il/library/windows/desktop/aa380513(v=vs.85).aspx
וגם פה:
https://www.ibm.com/support/knowled...oc/sy10660_.htm


לא מסתדר לי משהו.
בהתחלה, כתוב שהקליינט שולח, בין היתר, Random value (אקראי הכוונה שעבר hash?)
אחר כך השרת שולח גם Radom value משלו.

בהמשך הקליינט שוב פעם שולח Random number שאיתו גם הקליינט וגם הסרבר יוצרים secret key.

לא הבנתי איפה באים לידי ביטוי הrandoms value מתחילת הsession, איפה פה זה עוזר ל authenication ואיך זה מתקשר ל random number שאיתו הם יחשבו את ה secret key?

בסרטון שראיתי ב Youtube הוא מסביר שה two way authentication הזה מונע man in the middle attack אבל לא ברור לי בדיוק איך.


אשמח שמישהו יעזור לי להבין את התהליך הזה
_____________________________________
תמונה שהועלתה על ידי גולש באתר ולכן אין אנו יכולים לדעת מה היא מכילה

תמונה שהועלתה על ידי גולש באתר ולכן אין אנו יכולים לדעת מה היא מכילה

תגובה ללא ציטוט תגובה עם ציטוט חזרה לפורום
  #2  
ישן 24-04-2017, 18:12
  שימיadmin שימי אינו מחובר  
מנהל פורומי "תכנות ובניית אתרים" ו"חומרה ורשתות"
 
חבר מתאריך: 25.10.01
הודעות: 42,775
בתגובה להודעה מספר 1 שנכתבה על ידי Musicman0 שמתחילה ב "SSL TLS Handshake"

עזוב את ה random value...

קודם כל צריך להבין איזו בעייה אנחנו מנסים לפתור כאן, ואיך השיטה עוזרת לנו לפתור את הבעייה.

הגדרת הבעייה: שני הצדדים מעוניים לשלוח מידע אחד לשני, כך שאם מישהו מאזין לו תוך כדי מעברו ברשת, הוא לא יוכל להבין שום דבר, משום שהוא יראה "זבל אקראי", ולעומת זאת שני הצדדים המשוחחים ביניהם, יוכלו לפענח כל אחד את המידע של השני, ויותר מזה, לדעת שהמידע אכן נשלח על ידי מי שהם חושבים ששלח את המידע - ולא מישהו אחר (MITM).

הפתרון הפשוט: הצפנה סימטרית. שני הצדדים מחזיקים במפתח הצפנה שתואם ביניהם מראש (PSK - Pre-Shared Key, כמו שאתה ודאי מכיר מהרשת האלחוטית שלך בבית), וקיים רק אצלם - אף אחד אחר לא יודע אותו. למשל, שניהם נפגשים ברחוב, וכותבים רצף אקראי של מספרים על שני פתקי נייר, שאותם הם לוקחים הביתה. ליתר בטחון הם גם עושים את זה מתחת לגג פח, כדי שהלווינים של ה NSA/CIA לא יוכלו לצלם את עצם הכתיבה.

סבבה, אז נשתמש כולנו במפתחות כאלה, והכל יהיה מצויין, לא?

לא. למה?

משום שזה אומר שעבור כל אתר מוצפן שבו תרצה לגלוש (גוגל ו GMail, הבנק שלך, PayPal, פרש ), תצטרך להיפגש ברחוב עם אחראי התקשורת המוצפנת של האתר (שהרבה פעמים נמצא בכלל בארץ אחרת) - כדי להחליף איתו פתקים. תזכור שאסור לשלוח את המפתח בשום דרך אחרת שאינה מוצפנת, משום שכל מי שיאזין לתקשורת, יקבל את המפתח, ואז יוכל לפענח את התשדורת העתידית שהוצפנה איתו.

אז מה עשו? המציאו הצפנה א-סימטרית.

בהצפנה א-סימטרית, משתמשים בפטנט של מפתח פרטי ומפתח ציבורי, שיש ביניהם קשר מתמטי. כלומר, בהנתן מפתח פרטי, תמיד יופק ממנו אותו מפתח ציבורי. מה הטריק? שהפוך זה לא עובד - מהמפתח הציבורי לא ניתן להפיק את המפתח הפרטי שיצר אותו.

מבלי להיכנס למתמטיקה שמאחורי זה, אתה צריך לדעת את הכללים הבאים:
מידע שהוצפן על ידי ב' באמצעות מפתח ציבורי א', ניתן לפענח רק באמצעות המפתח הפרטי א'
מידע שנחתם דיגיטלית באמצעות מפתח פרטי א', צד ב' יכול להשתמש במפתח הציבורי של א' כדי לדעת בוודאות שההודעה נחתמה על ידי מחזיק במפתח פרטי א' (מי חתם) ושהיא מקורית (not tempered with)

בהנתן ההנחות הנ"ל, אנחנו יכולים להגיע לדבר הבא:

אם א' מתחבר אל ב', וב' מציג בפניו מפתח ציבורי (למשל כחלק מתעודה דיגיטלית), אזי א' יכול להשתמש במפתח הציבורי שהוא קיבל מב', לקחת מידע סודי, להצפין אותו באמצעות המפתח הציבורי של א', ולשלוח אותו לא'.
א', בתורו, כיוון שיש לו את המפתח הפרטי, יכול לקחת את המידע שהוצפן על ידי ב', ולפענחו. רק א' יכול לעשות את זה, כי רק ל-א' יש את המפתח הפרטי. עכשיו ל-א' ול-ב' יש עותקים של המידע הסודי - ורק להם. המידע הסודי הזה יכול להיות מפתח הצפנה סימטרי, ובעצם מאותו שלב יכולה להתבצע הצפנה סימטרית (שהיא מהירה יותר וצורכת פחות משאבים מהצפנה א-סימטרית) - למרות ששני הצדדים לא היו צריכים להיפגש ברחוב.

האם סיימנו ואנחנו מאובטחים? לא. למה?

משום שאנחנו עדיין פגיעים להתקפת MITM. למה?

נניח ש-ג' חוטף את התקשורת ש-א' מנסה לעשות מול ב', ועונה ל-א' כאילו הוא ב'. א' לא יודע שחטפו את התקשורת (איך ידע?), ולכן הוא לוקח את המפתח הציבורי ש-ג' מציג לו (שהוא חושב ששייך ל-ב'), ומצפין את המפתח הסימטרי הסודי באמצעותו, ושולח אותו ל-ג' (תוך שהוא חושב שהוא שלח אותו ל-ב'). מכאן יכולים לקרות שני מקרים - או שהתוקף ממש מתאמץ ויוצר אתר שנראה ממש כמו האתר שאותו הוא מנסה לתקוף, וגם מתנהג ממש כמוהו - או - אם הוא חכם יותר, הוא פשוט לוקח את הבקשות שהגיעו מ-א', ויוצר בקשות חדשות, זהות, אל ב' - כך שהוא הלקוח מול ב', שמבחינתו עסקים כרגיל. התקשורת בין א' ל-ג' מוצפנת, התקשורת בין ג' ל-ב' גם היא מוצפנת, ולכל מה שעובר בין הלקוח (א') לשרת (ב') יש עכשיו שלוש (או שש, אם תרצה) עיניים: א', ב', ו...ג'. זוהי התקפת MITM.

איך מונעים?

הבעייה שלנו היא שאנחנו לא יודעים שמי שמחזיר לנו תשובה, הוא מי שאנחנו חושבים שהוא. לשם כך הומצא המנגנון של תעודות דיגיטלית, אשר מכילות את המפתח הציבורי של הבעלים האמיתיים של האתר (בעלי הדומיין), שזהותם אומתה על ידי הוכחת בעלות על הדומיין (למשל על ידי הוספת קובץ באתר או מחרוזת כלשהי בדף הראשי של האתר לבקשת הגוף המאמת, או הוספת רשומה ב DNS, וכיוצ"ב. יש אפילו אימותים מתקדמים יותר, מול רשומות מוסדיות, כדי להנפיק תעודות "ירוקות", מה שנקרא EV - Extended Validation. אבל זה רק קוסמטי, אתר עם ירוק בשורת הכתובת לא מוצפן יותר טוב מאתר שלא. למעשה, תלוי בקונפיגורציה, הוא אפילו יכול להיות מוצפן פחות טוב. זה סתם דגל על התעודה. מה שכן זה גם מכיל את שם הגוף או האדם שזהותו אומתה, מה שתעודה רגילה לא מכילה.). את האימות הזה התעודה באה לתת. התעודה המדוברת, חתומה באמצעות המפתח הפרטי של הגוף המאמת, ולכן, כל מי שיש לו את המפתח הציבורי של הגוף המאמת, יכול לוודא (ראה לעיל) שהתעודה הופקה על ידי מי שחושבים שהפיק אותה, שלא נעשה בה כל שינוי (תאריך, זהות האתר המאומת, או hash המפתח הציבורי שלו), ולכן, אם יש התאמה בין התעודה לשם האתר, אפשר בבטחה להשתמש במפתח הציבורי שבתעודה כדי להצפין מידע שרק בעל האתר האמיתי יוכל לקרוא, שהרי רק בעל הדומיין האמיתי אמור להצליח להפיק תעודה אצל המאמת עבור הדומיין שלו. חשוב לציין שלשם כך אנחנו בוטחים במפיק התעודה (הלא הוא ה CA), ושלבטחון זה יש בעיות משלו (חפש DigiNotar ותבין למה). לשם כך נבנו מנגנונים נוספים שמוסיפים עוד שכבות הגנה - כמו HPKP ו DNS CAA). כמו כן אנחנו מניחים שהאתר המקורי לא נפרץ ושהמפתח הפרטי שלו אכן פרטי, אחרת, כל אחד יוכל להציג את התעודה (שהיא פומבית בעצם), ולהשתמש במפתח הפרטי ולהתחזות כאילו הוא האתר האמיתי, למרות שאינו יכול לבדו לארגן לעצמו תעודה חתומה עבור הדומיין של האתר המותקף.

זה על רגל אחת... מקווה שלא סיבכתי יותר מדי
_____________________________________
תמונה שהועלתה על ידי גולש באתר ולכן אין אנו יכולים לדעת מה היא מכילה
נמאס לכם לזכור סיסמאות? לחצו כאן!

תגובה ללא ציטוט תגובה עם ציטוט חזרה לפורום
  #4  
ישן 24-04-2017, 22:37
  שימיadmin שימי אינו מחובר  
מנהל פורומי "תכנות ובניית אתרים" ו"חומרה ורשתות"
 
חבר מתאריך: 25.10.01
הודעות: 42,775
בתגובה להודעה מספר 3 שנכתבה על ידי Musicman0 שמתחילה ב "וואו תודה רבה על התשובה..."

ובכן, תרשים מספר 1 בקישור של IBM בהודעה שלך, הוא, למיטב זכרוני, תרשים די מדוייק של ההודעות שעוברות ב negotiation.

אבל אתה יכול פשוט לפתוח wireshark ולראות בעצמך..

או יותר פשוט! curl... הנה על פרש:

ציטוט:
במקור נכתב על ידי curl
$ curl -v https://www.fresh.co.il
* Rebuilt URL to: https://www.fresh.co.il/
* Trying 54.246.111.111...
* TCP_NODELAY set
* Connected to www.fresh.co.il (54.246.111.111) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@ STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* NPN, negotiated HTTP2 (h2)
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Unknown (67):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-ECDSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: OU=Domain Control Validated; OU=GGSSL Wildcard SSL; CN=*.fresh.co.il
* start date: Dec 31 00:00:00 2016 GMT
* expire date: Dec 31 23:59:59 2019 GMT
* subjectAltName: host "www.fresh.co.il" matched cert's "*.fresh.co.il"
* issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO ECC Domain Validation Secure Server CA
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x137f270)
> GET / HTTP/1.1
> Host: www.fresh.co.il
> User-Agent: curl/7.52.1
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 301
< server: nginx
< date: Mon, 24 Apr 2017 19:36:32 GMT
< content-type: text/html
< location: https://www.fresh.co.il/vBulletin/
< strict-transport-security: max-age=15552000; includeSubDomains
< public-key-pins: pin-sha256="msP9V3W/2cTy5cE7tabVs3/7f7FdcNg6PYlv/XXHtqA="; pin-sha256="45YHa1ptkytrxQsQqiOUYx21lYIPBfC9K8r/TJte+SA="; pin-sha256="QWRQgm35VWtEvoiyOglOaCQ/iizKeTFbKrbwhXlp/1s="; pin-sha256="iE7GA3DiKs1Y5jkRmi+TcnvTGQAIjCoPC5H4Zb2tl4c="; pin-sha256="FblLW1imWuLxayYTy1AZqSGdYTQFWO4KTUVPbAtyE1U="; pin-sha256="tKjZ7/v6IVMIW+8Q/XO32kcKkFLCVqfOT4kwOk/qESw="; max-age=2592000; includeSubDomains; report-uri="https://fresh.report-uri.io/r/default/hpkp/enforce"
< x-frame-options: SAMEORIGIN
< x-xss-protection: 1; mode=block
< x-content-type-options: nosniff
< referrer-policy: same-origin
<
* Curl_http_done: called premature == 0
* Connection #0 to host www.fresh.co.il left intact


אם כי זה שלמעלה יכול קצת לבלבל כי הוא תומך ב HTTP/2 רק דרך NPN כרגע, ולא דרך הפרוטוקול המודרני יותר (ALPN) אשר חוסך negotiation מיותר. אז הנה על שרת אחר של פרש שכבר תומך גם ב ALPN:

ציטוט:
במקור נכתב על ידי curl

$ curl -v https://static.fresh.co.il
* Rebuilt URL to: https://static.fresh.co.il/
* Trying 52.222.157.11...
* TCP_NODELAY set
* Connected to static.fresh.co.il (52.222.157.11) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@ STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
* subject: OU=Domain Control Validated; OU=GGSSL Wildcard SSL; CN=*.fresh.co.il
* start date: Dec 31 00:00:00 2016 GMT
* expire date: Dec 31 23:59:59 2019 GMT
* subjectAltName: host "static.fresh.co.il" matched cert's "*.fresh.co.il"
* issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO RSA Domain Validation Secure Server CA
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0xb8c270)
> GET / HTTP/1.1
> Host: static.fresh.co.il
> User-Agent: curl/7.52.1
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 403
< content-type: application/xml
< x-amz-bucket-region: eu-west-1
< date: Mon, 24 Apr 2017 19:48:27 GMT
< server: AmazonS3
< x-cache: Error from cloudfront
< via: 1.1 bc9bd2c59aa48e2932432099ba36a25b.cloudfront.net (CloudFront)
< x-amz-cf-id: G78PA7seolPlLxyb5a1KOqW85Oga-aAWxvAjOhJW5iKhu_H705creg==
<
<?xml version="1.0" encoding="UTF-8"?>
* Curl_http_done: called premature == 0
* Connection #0 to host static.fresh.co.il left intact
<Error><Code>AccessDenied</Code><Message>Access Denied</Message><RequestId>AE90457E127CA193</RequestId><HostId>lOLHQTwn8mUp7ALtXruOk3YTkKwiiLxjEMHw71Q8VpsKV/hYQm6ol504J8TjNODf9EK/C749dxo=</HostId></Error>
_____________________________________
תמונה שהועלתה על ידי גולש באתר ולכן אין אנו יכולים לדעת מה היא מכילה
נמאס לכם לזכור סיסמאות? לחצו כאן!

תגובה ללא ציטוט תגובה עם ציטוט חזרה לפורום
  #5  
ישן 25-04-2017, 09:53
צלמית המשתמש של Musicman0
  משתמש זכר Musicman0 Musicman0 אינו מחובר  
 
חבר מתאריך: 25.12.05
הודעות: 5,004
בתגובה להודעה מספר 4 שנכתבה על ידי שימי שמתחילה ב "ובכן, תרשים מספר 1 בקישור של..."

היי, תודה
אכן הcurl דיי זהה לתרשים שיש ב IBM.

אבל עדיין יש כמה דברים שלא ברורים לי, לפחות ממה שמוסבר בIBM:
הם מדברים שם על Random Value, מה זה?
אומנם כתבת בהודעה הראשונה לעזוב את זה, אבל אני מבין שזה כן חלק אינטגרלי מhandshake
מכיוון שבשלב ה4 (IBM) כתוב שהקליינט שולח את הrandom value מוצפן ע"י sever's public key
והוא ישמש את שניהם ליצירת ה secret key.
אוקיי. אז יש סטרינג כלשהו שמשמש אותם ליצירת המפתח הסימטרי.

אבל בשלבים 1 ו-2 בIBM
כתוב ש
שלב 1: client send random value
שלב 2. server send random value

למה זה מועיל בשלב 1 ו-2? איך זה עוזר לאבטחה, איפה מאמתים ואיך מאמתים את הrandom value הזה?
איפה בא לידי ביטוי פה ה- two way authentication?
האם ה random value משלב 1 ו-2 זה אותו ערך? ואם כן (או לא), האם זה אותו ערך משלב 4?
האם random value פירושו שעבר גיבוב?

באחד המאמרים שקראיתי (DTLS Hanshake) גם היה כתוב שיש שימוש לפעמים ב HMAC-SHA1 (ידוע לי ש SHA1 כבר לא אמין בכל בכל זאת), ולא הבנתי איפה זה בא לידי ביטוי, ואם בכלל הבנתי נכון או שאני עושה סלט עכשיו?

כמו כן,אני לא רואה למה בשלבים 1ו-2 לא יכול להיות גורם שלישי (MITM) שיוכל להשיג כל מידע שהו עובר מצד לצד, ובעצם להתחזות לאחר.


תודה
_____________________________________
תמונה שהועלתה על ידי גולש באתר ולכן אין אנו יכולים לדעת מה היא מכילה

תמונה שהועלתה על ידי גולש באתר ולכן אין אנו יכולים לדעת מה היא מכילה


נערך לאחרונה ע"י Musicman0 בתאריך 25-04-2017 בשעה 09:58.
תגובה ללא ציטוט תגובה עם ציטוט חזרה לפורום
  #6  
ישן 26-04-2017, 00:11
  שימיadmin שימי אינו מחובר  
מנהל פורומי "תכנות ובניית אתרים" ו"חומרה ורשתות"
 
חבר מתאריך: 25.10.01
הודעות: 42,775
בתגובה להודעה מספר 5 שנכתבה על ידי Musicman0 שמתחילה ב "היי, תודה אכן הcurl דיי זהה..."

אני לא יכול לעשות הרבה חוץ מלתרגם לך לעברית. random value הוא ערך אקראי, שאורכו במקרה הזה הוא 28 בתים. ערך אקראי אמיתי (קצת קשה לייצר אותם בלי לדגום משהו אקראי מהטבע כמו דעיכה של חומר רדיואקטיבי) פירושו שאין לך כל דרך לחזות מה יהיו הביטים בכל אחד מהבתים.

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

אשר לשלבים 1 ו-2 - ודאי שיכול להתחזות, זה הרי בדיוק תיאור ה MITM שהצגתי. את הטענה שהוא יכול להשיג מידע שעבר מצד לצד (אחרי שהושלם ה negotiation של ההצפנה) סתרתי בתגובתי הקודמת: הלקוח מוודא את התעודה הדיגיטלית שהשרת הציג לו; אם התעודה המוצגת לא מתאימה לשרת - תקבל שגיאה. אם היא מתאימה לשרת אך לא חתומה על ידי מישהו שאתה בוטח בו - תקבל שגיאה. אם היא חתומה על ידי מישהו שאתה בוטח בו אך מי שמציג לך את התעודה הוא תוקף MITM - אזי לתוקף אין את המפתח הפרטי שהפיק את המפתח הציבורי שבתעודה, וכשאתה תשלח הודעה מוצפנת עם הציבורי שבתעודה - הוא לא יצליח לפענח את ההודעה, ולכן הוא לא "יוכל להשיג כל מידע שהו עובר מצד לצד", כפי שאמרת.
_____________________________________
תמונה שהועלתה על ידי גולש באתר ולכן אין אנו יכולים לדעת מה היא מכילה
נמאס לכם לזכור סיסמאות? לחצו כאן!

תגובה ללא ציטוט תגובה עם ציטוט חזרה לפורום
תגובה

כלי אשכול חפש באשכול זה
חפש באשכול זה:

חיפוש מתקדם
מצבי תצוגה דרג אשכול זה
דרג אשכול זה:

מזער את תיבת המידע אפשרויות משלוח הודעות
אתה לא יכול לפתוח אשכולות חדשים
אתה לא יכול להגיב לאשכולות
אתה לא יכול לצרף קבצים
אתה לא יכול לערוך את ההודעות שלך

קוד vB פעיל
קוד [IMG] פעיל
קוד HTML כבוי
מעבר לפורום



כל הזמנים המוצגים בדף זה הם לפי איזור זמן GMT +2. השעה כעת היא 18:18

הדף נוצר ב 0.18 שניות עם 10 שאילתות

הפורום מבוסס על vBulletin, גירסא 3.0.6
כל הזכויות לתוכנת הפורומים שמורות © 2024 - 2000 לחברת Jelsoft Enterprises.
כל הזכויות שמורות ל Fresh.co.il ©

צור קשר | תקנון האתר