Android studio
-
@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 -
-
-
@dovid יכול להיות שזה יעזור?
מכיר את הכלי הזה?
https://stackoverflow.com/questions/26192713/android-studio-servers-certificate-is-not-trusted/37708933#37708933
ציטוט:
It is missing system certificate specific for Java. If you are using Ubuntu and Oracle JRE/JDK, install ca-certificates-java package.
