Android studio
-
@מנצפך אמר בAndroid studio:
@dovid יפתחו כל חבילה ויבדקו בנפרד. חבילה טובה ישלחו כמו שהיא בלי לחתום מחדש.
אם לדוגמא יש בקשת get סטדנדרטית (HTTPS). כמה חבילות נשלחות בתשובה?
אם חבילה אחת זה ממש פשוט. אבל גם אם זה כמה חבילות, אפשר לבדוק כל חבילה ואם אין בה בעיה לשלוח אותה כמו שהיא. וגם אם נניח שצריך לשמור כמה חבילות ולפתוח אותם ביחד, אז גם אפשר לעשות שאם כולן תקינות, ישלחו כולן סגורות בחתימה המקורית.זה לא עניין של לפתוח לסגור. אני אסביר לך את הרעיון:
בתחילת ההתקשרות האתר מבקש מהגולש קוד-מפתח שאפשר להצפין בו בצורה חד כיוונית. הלקוח שולח כזה קוד שהוא ממציא לצורך התקשרות. האתר לוקח את התשובה, ומצפין אותה עם המפתח הזה. אחרי אריזת חבילה עם מפתח שהלקוח סיפק אף אחד בעולם כולל האתר עצמו לא יכולים לפתוח חזרה את החבילה חוץ מהלקוח שסיפק את המפתח - האקראי.
אז איך נטפרי יכולה לפתוח חבילות?
פשוט מאוד, היא מתחזה ללקוח. היא שולחת מפתח הצפנה משלה (לא את של הלקוח), האתר סוגר את החבילה עם המפתח שנטפרי סיפקה, ואז נטפרי יכולים לפתוח אבל הלקוח האמיתי לא! ואז נטפרי פותחת את ההצפנה, וסוגרת את זה שוב והפעם עם המפתח שהלקוח סיפק בתחילת הסיפור. ככה הלקוח יכול לפתוח אלא שאז הוא מגלה שהסוגר איננו האתר, אלא נטפרי.אני לא מספיק מכיר את איך הדברים עובדים אבל כן מכיר את הסימבוליקה.
-
-
@מנצפך אף אחד לא בודק חבילה, חבילה זה מאד קטן (חבילת TCP - Packet). בודקים את התוכן. בקשת GET יכולה להיות מורכבת ממספר חבילות.
הבעיה כעת שהתוכנה לא מוכנה לקבל את התוכן שנבדק בגלל שהפרוקסי קרא את התעבורה המוצפנת. לא שהתשובה לא הגיעה מסוננת.אבל אולי אפשר שאם אין בכלל בעיה בתוכן, לפנות שוב לשרת המקורי ולא לפתוח ולהעביר ישר כמו שזה ללקוח.
-
@5566brs אמר בAndroid studio:
@מנצפך אף אחד לא בודק חבילה, חבילה זה מאד קטן (חבילת TCP - Packet). בודקים את התוכן. בקשת GET יכולה להיות מורכבת ממספר חבילות.
הבעיה כעת שהתוכנה לא מוכנה לקבל את התוכן שנבדק בגלל שהפרוקסי קרא את התעבורה המוצפנת. לא שהתשובה לא הגיעה מסוננת.אבל אולי אפשר שאם אין בכלל בעיה בתוכן, לפנות שוב לשרת המקורי ולא לפתוח ולהעביר ישר כמו שזה ללקוח.
מוכרח להיות שאי אפשר. המטרה של SSL היא (בעיקר) להבטיח שאין מישהו באמצע.
אם מישהו באמצע יכל לקרוא, ואז לבקש שוב ולהחזיר "בלי לגעת" אז SSL החמיץ את כל מטרתו. -
@dovid אכן לפי התיאור הקצר הבא (שלקוח מכאן) אין דרך לגרום לזה לקרות:
"כדי להתחיל תקשורת בין שני צדדים, הם משתמשים בהצפנה פומבית כדי להעביר בצורה בטוחה מפתח מצד אחד לשני. אחרי כן, שני הצדדים משתמשים במפתח המשותף הזה להצפנה סימטרית (מהירה פי כמה)".
אין דרך לבקש משהו בשם מישהו, כשהבקשה אמורה להיות מוצפנת באופן שאין אפשרות להתערב בה. -
@5566brs אמר בAndroid studio:
@מנצפך אף אחד לא בודק חבילה, חבילה זה מאד קטן (חבילת TCP - Packet). בודקים את התוכן. בקשת GET יכולה להיות מורכבת ממספר חבילות.
הבעיה כעת שהתוכנה לא מוכנה לקבל את התוכן שנבדק בגלל שהפרוקסי קרא את התעבורה המוצפנת. לא שהתשובה לא הגיעה מסוננת.אבל אולי אפשר שאם אין בכלל בעיה בתוכן, לפנות שוב לשרת המקורי ולא לפתוח ולהעביר ישר כמו שזה ללקוח.
בא נסביר ככה HTTP זה בתוך פרוטוקול זרימה שהוא בתוך פרוטוקל הצפנה TLS שהוא עובד על פרוטוקול זרימה כמו TCP. ה TLS לא יודע בכלל מה זה חבילות זה העבודה של ה TCP. וזה אומר שההצפנה היא על הכל.
אי אפשר לראות URL הדבר היחיד שאפשר לדעת וגם לא בצורה ודאית זה הדומיין בגלל שמשתמשים בו בהתחלת האימות. -
@dovid אמר בAndroid studio:
@5566brs אמר בAndroid studio:
@מנצפך אף אחד לא בודק חבילה, חבילה זה מאד קטן (חבילת TCP - Packet). בודקים את התוכן. בקשת GET יכולה להיות מורכבת ממספר חבילות.
הבעיה כעת שהתוכנה לא מוכנה לקבל את התוכן שנבדק בגלל שהפרוקסי קרא את התעבורה המוצפנת. לא שהתשובה לא הגיעה מסוננת.אבל אולי אפשר שאם אין בכלל בעיה בתוכן, לפנות שוב לשרת המקורי ולא לפתוח ולהעביר ישר כמו שזה ללקוח.
מוכרח להיות שאי אפשר. המטרה של SSL היא (בעיקר) להבטיח שאין מישהו באמצע.
אם מישהו באמצע יכל לקרוא, ואז לבקש שוב ולהחזיר "בלי לגעת" אז SSL החמיץ את כל מטרתו.@5566brs למה צריך לפנות שוב לשרת? אי אפשר להעביר את התעבורה כמו שהיתה לפני שנפתחה?
@dovid אני חושב שמה שאי אפשר (במקרה של פרוקסי כמו נטפרי שיש לו, איך שאני מבין את המפתח הסימטרי) זה לשנות את התעבורה. כי אז יראו שהיא נפתחה. אבל וודאי שאפשר לקרוא את התוכן.
אם בלבלתי בשכל פשוט תגידו את זה. -
@מנצפך אמר בAndroid studio:
@dovid אמר בAndroid studio:
@5566brs אמר בAndroid studio:
@מנצפך אף אחד לא בודק חבילה, חבילה זה מאד קטן (חבילת TCP - Packet). בודקים את התוכן. בקשת GET יכולה להיות מורכבת ממספר חבילות.
הבעיה כעת שהתוכנה לא מוכנה לקבל את התוכן שנבדק בגלל שהפרוקסי קרא את התעבורה המוצפנת. לא שהתשובה לא הגיעה מסוננת.אבל אולי אפשר שאם אין בכלל בעיה בתוכן, לפנות שוב לשרת המקורי ולא לפתוח ולהעביר ישר כמו שזה ללקוח.
מוכרח להיות שאי אפשר. המטרה של SSL היא (בעיקר) להבטיח שאין מישהו באמצע.
אם מישהו באמצע יכל לקרוא, ואז לבקש שוב ולהחזיר "בלי לגעת" אז SSL החמיץ את כל מטרתו.@5566brs למה צריך לפנות שוב לשרת? אי אפשר להעביר את התעבורה כמו שהיתה לפני שנפתחה?
@dovid אני חושב שמה שאי אפשר (במקרה של פרוקסי כמו נטפרי שיש לו, איך שאני מבין את המפתח הסימטרי) זה לשנות את התעבורה. כי אז יראו שהיא נפתחה. אבל וודאי שאפשר לקרוא את התוכן.
אם בלבלתי בשכל פשוט תגידו את זה.חבל, השקעתי בתשובה כבר אתמול ובחרת שלא להתאמץ להבין אותה.
לא בלבלת בשכל, רק טעית. הSSL בא לשתי דברים: וידוא מול מי אתה מתעסק, ווידוא שאף אחד לא מצוטט לתקשורת מולו. אתה מדבר רק על וידוא שלמות - שזה גם חלק קריפטוגרפי חשוב בהרבה נושאים אבל בSSL הוא רק פועל יוצא. -
-
@מנצפך אמר בAndroid studio:
@dovid אבל נטפרי יכולים לקרוא את התעבורה. נכון? והם גם יכולים לבחור אם להעביר אותה כמו שהיא או לשנות אותה ולחתום במפתח שלהם. אז מה הבעיה שאם הם רואים תקשורת לא בעייתית, יעבירו אותה בשלמותה?
אם הם מעבירים אותה בשלמותה זה לא משנה את המפתח שלה.יש מצב שאתה מאמין לי שלקרוא את מה שכתבתי יפתור את שאלתך?
-
בדקתי אצלי באובנטו. גם אצלי לא עובד.
sudo /usr/bin/keytool --noprompt --trustcacerts --keystore /usr/lib/jvm/java-8-oracle/jre/lib/security/cacerts --importcert --alias nf --file ~/netfree-ca.crt --storepass changeitכנ"ל:
sudo /usr/bin/keytool --noprompt --trustcacerts --keystore .AndroidStudio3.1/system/tasks/cacerts --importcert --alias nf --file ~/netfree-ca.crt --storepass changeit -
-
