Android studio
-
@מנצפך אמר בAndroid studio:
@dovid יפתחו כל חבילה ויבדקו בנפרד. חבילה טובה ישלחו כמו שהיא בלי לחתום מחדש.
אם לדוגמא יש בקשת get סטדנדרטית (HTTPS). כמה חבילות נשלחות בתשובה?
אם חבילה אחת זה ממש פשוט. אבל גם אם זה כמה חבילות, אפשר לבדוק כל חבילה ואם אין בה בעיה לשלוח אותה כמו שהיא. וגם אם נניח שצריך לשמור כמה חבילות ולפתוח אותם ביחד, אז גם אפשר לעשות שאם כולן תקינות, ישלחו כולן סגורות בחתימה המקורית.זה לא עניין של לפתוח לסגור. אני אסביר לך את הרעיון:
בתחילת ההתקשרות האתר מבקש מהגולש קוד-מפתח שאפשר להצפין בו בצורה חד כיוונית. הלקוח שולח כזה קוד שהוא ממציא לצורך התקשרות. האתר לוקח את התשובה, ומצפין אותה עם המפתח הזה. אחרי אריזת חבילה עם מפתח שהלקוח סיפק אף אחד בעולם כולל האתר עצמו לא יכולים לפתוח חזרה את החבילה חוץ מהלקוח שסיפק את המפתח - האקראי.
אז איך נטפרי יכולה לפתוח חבילות?
פשוט מאוד, היא מתחזה ללקוח. היא שולחת מפתח הצפנה משלה (לא את של הלקוח), האתר סוגר את החבילה עם המפתח שנטפרי סיפקה, ואז נטפרי יכולים לפתוח אבל הלקוח האמיתי לא! ואז נטפרי פותחת את ההצפנה, וסוגרת את זה שוב והפעם עם המפתח שהלקוח סיפק בתחילת הסיפור. ככה הלקוח יכול לפתוח אלא שאז הוא מגלה שהסוגר איננו האתר, אלא נטפרי.אני לא מספיק מכיר את איך הדברים עובדים אבל כן מכיר את הסימבוליקה.
-
@dovid את זה אני יודע פחות או יותר.
שאלתי בעינה. ברור שצריכים להתקין תעודה.
אבל עדיין אם אני פותח חבילה ואני רואה שהיא בסדר אני יכול להעביר אותה כמו שהיא בלי לחתום מחדש.
על זה אתה מסכים? -
@dovid את זה אני יודע פחות או יותר.
שאלתי בעינה. ברור שצריכים להתקין תעודה.
אבל עדיין אם אני פותח חבילה ואני רואה שהיא בסדר אני יכול להעביר אותה כמו שהיא בלי לחתום מחדש.
על זה אתה מסכים? -
ה proxy שפותח את התעבורה לא עובד בצורה של חבילה אחרי חבילה?
אם יש בקשת HTTPS GET. אין כמה חבילות בתשובה,
וה proxy פותח את כולם ואז מעביר ללקוח את התשובה המסוננת?@מנצפך אף אחד לא בודק חבילה, חבילה זה מאד קטן (חבילת TCP - Packet). בודקים את התוכן. בקשת GET יכולה להיות מורכבת ממספר חבילות.
הבעיה כעת שהתוכנה לא מוכנה לקבל את התוכן שנבדק בגלל שהפרוקסי קרא את התעבורה המוצפנת. לא שהתשובה לא הגיעה מסוננת.אבל אולי אפשר שאם אין בכלל בעיה בתוכן, לפנות שוב לשרת המקורי ולא לפתוח ולהעביר ישר כמו שזה ללקוח.
-
@מנצפך אף אחד לא בודק חבילה, חבילה זה מאד קטן (חבילת TCP - Packet). בודקים את התוכן. בקשת GET יכולה להיות מורכבת ממספר חבילות.
הבעיה כעת שהתוכנה לא מוכנה לקבל את התוכן שנבדק בגלל שהפרוקסי קרא את התעבורה המוצפנת. לא שהתשובה לא הגיעה מסוננת.אבל אולי אפשר שאם אין בכלל בעיה בתוכן, לפנות שוב לשרת המקורי ולא לפתוח ולהעביר ישר כמו שזה ללקוח.
@5566brs אמר בAndroid studio:
@מנצפך אף אחד לא בודק חבילה, חבילה זה מאד קטן (חבילת TCP - Packet). בודקים את התוכן. בקשת GET יכולה להיות מורכבת ממספר חבילות.
הבעיה כעת שהתוכנה לא מוכנה לקבל את התוכן שנבדק בגלל שהפרוקסי קרא את התעבורה המוצפנת. לא שהתשובה לא הגיעה מסוננת.אבל אולי אפשר שאם אין בכלל בעיה בתוכן, לפנות שוב לשרת המקורי ולא לפתוח ולהעביר ישר כמו שזה ללקוח.
מוכרח להיות שאי אפשר. המטרה של SSL היא (בעיקר) להבטיח שאין מישהו באמצע.
אם מישהו באמצע יכל לקרוא, ואז לבקש שוב ולהחזיר "בלי לגעת" אז SSL החמיץ את כל מטרתו.- מנטור אישי בתכנות והמסתעף – להתקדם לשלב הבא!
- בכל נושא אפשר ליצור קשר dovid@tchumim.com
-
@5566brs אמר בAndroid studio:
@מנצפך אף אחד לא בודק חבילה, חבילה זה מאד קטן (חבילת TCP - Packet). בודקים את התוכן. בקשת GET יכולה להיות מורכבת ממספר חבילות.
הבעיה כעת שהתוכנה לא מוכנה לקבל את התוכן שנבדק בגלל שהפרוקסי קרא את התעבורה המוצפנת. לא שהתשובה לא הגיעה מסוננת.אבל אולי אפשר שאם אין בכלל בעיה בתוכן, לפנות שוב לשרת המקורי ולא לפתוח ולהעביר ישר כמו שזה ללקוח.
מוכרח להיות שאי אפשר. המטרה של SSL היא (בעיקר) להבטיח שאין מישהו באמצע.
אם מישהו באמצע יכל לקרוא, ואז לבקש שוב ולהחזיר "בלי לגעת" אז SSL החמיץ את כל מטרתו.@dovid אכן לפי התיאור הקצר הבא (שלקוח מכאן) אין דרך לגרום לזה לקרות:
"כדי להתחיל תקשורת בין שני צדדים, הם משתמשים בהצפנה פומבית כדי להעביר בצורה בטוחה מפתח מצד אחד לשני. אחרי כן, שני הצדדים משתמשים במפתח המשותף הזה להצפנה סימטרית (מהירה פי כמה)".
אין דרך לבקש משהו בשם מישהו, כשהבקשה אמורה להיות מוצפנת באופן שאין אפשרות להתערב בה. -
@מנצפך אף אחד לא בודק חבילה, חבילה זה מאד קטן (חבילת TCP - Packet). בודקים את התוכן. בקשת GET יכולה להיות מורכבת ממספר חבילות.
הבעיה כעת שהתוכנה לא מוכנה לקבל את התוכן שנבדק בגלל שהפרוקסי קרא את התעבורה המוצפנת. לא שהתשובה לא הגיעה מסוננת.אבל אולי אפשר שאם אין בכלל בעיה בתוכן, לפנות שוב לשרת המקורי ולא לפתוח ולהעביר ישר כמו שזה ללקוח.
@5566brs אמר בAndroid studio:
@מנצפך אף אחד לא בודק חבילה, חבילה זה מאד קטן (חבילת TCP - Packet). בודקים את התוכן. בקשת GET יכולה להיות מורכבת ממספר חבילות.
הבעיה כעת שהתוכנה לא מוכנה לקבל את התוכן שנבדק בגלל שהפרוקסי קרא את התעבורה המוצפנת. לא שהתשובה לא הגיעה מסוננת.אבל אולי אפשר שאם אין בכלל בעיה בתוכן, לפנות שוב לשרת המקורי ולא לפתוח ולהעביר ישר כמו שזה ללקוח.
בא נסביר ככה HTTP זה בתוך פרוטוקול זרימה שהוא בתוך פרוטוקל הצפנה TLS שהוא עובד על פרוטוקול זרימה כמו TCP. ה TLS לא יודע בכלל מה זה חבילות זה העבודה של ה TCP. וזה אומר שההצפנה היא על הכל.
אי אפשר לראות URL הדבר היחיד שאפשר לדעת וגם לא בצורה ודאית זה הדומיין בגלל שמשתמשים בו בהתחלת האימות. -
@5566brs אמר בAndroid studio:
@מנצפך אף אחד לא בודק חבילה, חבילה זה מאד קטן (חבילת TCP - Packet). בודקים את התוכן. בקשת GET יכולה להיות מורכבת ממספר חבילות.
הבעיה כעת שהתוכנה לא מוכנה לקבל את התוכן שנבדק בגלל שהפרוקסי קרא את התעבורה המוצפנת. לא שהתשובה לא הגיעה מסוננת.אבל אולי אפשר שאם אין בכלל בעיה בתוכן, לפנות שוב לשרת המקורי ולא לפתוח ולהעביר ישר כמו שזה ללקוח.
מוכרח להיות שאי אפשר. המטרה של SSL היא (בעיקר) להבטיח שאין מישהו באמצע.
אם מישהו באמצע יכל לקרוא, ואז לבקש שוב ולהחזיר "בלי לגעת" אז SSL החמיץ את כל מטרתו.@dovid אמר בAndroid studio:
@5566brs אמר בAndroid studio:
@מנצפך אף אחד לא בודק חבילה, חבילה זה מאד קטן (חבילת TCP - Packet). בודקים את התוכן. בקשת GET יכולה להיות מורכבת ממספר חבילות.
הבעיה כעת שהתוכנה לא מוכנה לקבל את התוכן שנבדק בגלל שהפרוקסי קרא את התעבורה המוצפנת. לא שהתשובה לא הגיעה מסוננת.אבל אולי אפשר שאם אין בכלל בעיה בתוכן, לפנות שוב לשרת המקורי ולא לפתוח ולהעביר ישר כמו שזה ללקוח.
מוכרח להיות שאי אפשר. המטרה של SSL היא (בעיקר) להבטיח שאין מישהו באמצע.
אם מישהו באמצע יכל לקרוא, ואז לבקש שוב ולהחזיר "בלי לגעת" אז SSL החמיץ את כל מטרתו.@5566brs למה צריך לפנות שוב לשרת? אי אפשר להעביר את התעבורה כמו שהיתה לפני שנפתחה?
@dovid אני חושב שמה שאי אפשר (במקרה של פרוקסי כמו נטפרי שיש לו, איך שאני מבין את המפתח הסימטרי) זה לשנות את התעבורה. כי אז יראו שהיא נפתחה. אבל וודאי שאפשר לקרוא את התוכן.
אם בלבלתי בשכל פשוט תגידו את זה. -
@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 הוא רק פועל יוצא.- מנטור אישי בתכנות והמסתעף – להתקדם לשלב הבא!
- בכל נושא אפשר ליצור קשר dovid@tchumim.com
-
@מנצפך אמר בAndroid studio:
@dovid אמר בAndroid studio:
@5566brs אמר בAndroid studio:
@מנצפך אף אחד לא בודק חבילה, חבילה זה מאד קטן (חבילת TCP - Packet). בודקים את התוכן. בקשת GET יכולה להיות מורכבת ממספר חבילות.
הבעיה כעת שהתוכנה לא מוכנה לקבל את התוכן שנבדק בגלל שהפרוקסי קרא את התעבורה המוצפנת. לא שהתשובה לא הגיעה מסוננת.אבל אולי אפשר שאם אין בכלל בעיה בתוכן, לפנות שוב לשרת המקורי ולא לפתוח ולהעביר ישר כמו שזה ללקוח.
מוכרח להיות שאי אפשר. המטרה של SSL היא (בעיקר) להבטיח שאין מישהו באמצע.
אם מישהו באמצע יכל לקרוא, ואז לבקש שוב ולהחזיר "בלי לגעת" אז SSL החמיץ את כל מטרתו.@5566brs למה צריך לפנות שוב לשרת? אי אפשר להעביר את התעבורה כמו שהיתה לפני שנפתחה?
@dovid אני חושב שמה שאי אפשר (במקרה של פרוקסי כמו נטפרי שיש לו, איך שאני מבין את המפתח הסימטרי) זה לשנות את התעבורה. כי אז יראו שהיא נפתחה. אבל וודאי שאפשר לקרוא את התוכן.
אם בלבלתי בשכל פשוט תגידו את זה.חבל, השקעתי בתשובה כבר אתמול ובחרת שלא להתאמץ להבין אותה.
לא בלבלת בשכל, רק טעית. הSSL בא לשתי דברים: וידוא מול מי אתה מתעסק, ווידוא שאף אחד לא מצוטט לתקשורת מולו. אתה מדבר רק על וידוא שלמות - שזה גם חלק קריפטוגרפי חשוב בהרבה נושאים אבל בSSL הוא רק פועל יוצא.@dovid אבל נטפרי יכולים לקרוא את התעבורה. נכון? והם גם יכולים לבחור אם להעביר אותה כמו שהיא או לשנות אותה ולחתום במפתח שלהם. אז מה הבעיה שאם הם רואים תקשורת לא בעייתית, יעבירו אותה בשלמותה?
אם הם מעבירים אותה בשלמותה זה לא משנה את המפתח שלה. -
@dovid אבל נטפרי יכולים לקרוא את התעבורה. נכון? והם גם יכולים לבחור אם להעביר אותה כמו שהיא או לשנות אותה ולחתום במפתח שלהם. אז מה הבעיה שאם הם רואים תקשורת לא בעייתית, יעבירו אותה בשלמותה?
אם הם מעבירים אותה בשלמותה זה לא משנה את המפתח שלה.@מנצפך אמר בAndroid studio:
@dovid אבל נטפרי יכולים לקרוא את התעבורה. נכון? והם גם יכולים לבחור אם להעביר אותה כמו שהיא או לשנות אותה ולחתום במפתח שלהם. אז מה הבעיה שאם הם רואים תקשורת לא בעייתית, יעבירו אותה בשלמותה?
אם הם מעבירים אותה בשלמותה זה לא משנה את המפתח שלה.יש מצב שאתה מאמין לי שלקרוא את מה שכתבתי יפתור את שאלתך?
-
@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 -
@מנצפך אמר בAndroid studio:
@dovid
הוא כתב לך שהאישור נוסף בהצלחה?כן
(אגב, מה זה ה ~ בubuntu? תיקיית הבית של היוזר?)
כן
- מנטור אישי בתכנות והמסתעף – להתקדם לשלב הבא!
- בכל נושא אפשר ליצור קשר dovid@tchumim.com
-
@מנצפך אמר בAndroid studio:
@dovid
הוא כתב לך שהאישור נוסף בהצלחה?כן
(אגב, מה זה ה ~ בubuntu? תיקיית הבית של היוזר?)
כן
-
@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.
