Android studio

[dovid]

http://forum.netfree.link/topic/3429/android-studio/12

אכן בדקתי אצלי וכלום לא עוזר.

[מנצפך]

בעיה. איפה זה יכול להיות? באישור אבטחה?
אני גם ניסיתי את הקובץ הנ"ל ולא עוזר.
מרימים ידיים?

[dovid]

אפשר לנסות לפנות לנטפרי,
אני לא הצלחתי להבין מה הבעיה.

[מנצפך]

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

[dovid]

הן אכן כולם חתומות חוץ מגוגל, וא"א להשאיר חתום את גוגל...
ב"ה מצאתי פתרון:

• להוריד את התעודה ולישם במחשב במקום מסויים, למשל בC.

• נכנסים לשורת הפקודה כמנהל

• עוברים לתיקיה הבאה, ע"י CD:

   cd C:\Program Files\Android\Android Studio\jre\jre\bin
  

• מריצים את הפקוה הבאה:

  keytool --noprompt -trustcacerts -keystore ..\lib\security\cacerts -importcert -alias nf -file "C:\netfree-ca.crt" -storepass changeit
  

[מנצפך]

@dovid יש לך מושג איך אפשר ב Ubuntu?
מה מקור הפתרון? תודהרבה.

[מנצפך]

לכאו' אפשר גם ב ubuntu. עכשיו עשיתי. נראה אם זה יעוזר.
עריכה: בינתיים לא עובד. אותה בעיה.
@dovid בווינדוס זה עובד לך טוב? (תכף אבדוק בווינדוס).

[dovid]

@מנצפך אמר בAndroid studio:

@dovid בווינדוס זה עובד לך טוב? (תכף אבדוק בווינדוס).

כן.
תגיד מה עשית באובנטו ומה פלט הפקודות.

[dovid]

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

[מנצפך]

עשיתי CD לתיקיה jre\jre\bin
והרצתי את הפקודה keytool .... בציון המיקום הרלוונטי של התעודה.
זה כותב

  Certificate was added to keystore

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

[מנצפך]

בווינדוס זה בינתיים בסדר גמור. לא יודע מה הבעיה בלינוקס.

[dovid]

@מנצפך אמר בAndroid studio:

עשיתי CD לתיקיה jre\jre\bin
והרצתי את הפקודה keytool .... בציון המיקום הרלוונטי של התעודה.
זה כותב

  Certificate was added to keystore

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

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

[מנצפך]

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

[dovid]

@מנצפך אמר בAndroid studio:

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

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

אני לא מספיק מכיר את איך הדברים עובדים אבל כן מכיר את הסימבוליקה.

[מנצפך]

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

[dovid]

@מנצפך אמר בAndroid studio:

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

תקרא שוב.

[magicode]

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

[מנצפך]

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

[5566brs]

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

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

[dovid]

@5566brs אמר בAndroid studio:

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

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

מוכרח להיות שאי אפשר. המטרה של SSL היא (בעיקר) להבטיח שאין מישהו באמצע.
אם מישהו באמצע יכל לקרוא, ואז לבקש שוב ולהחזיר "בלי לגעת" אז SSL החמיץ את כל מטרתו.