שְׁאֵלָה:
מדוע DNS-over-HTTPS הוא סיוט אבטחה כה גדול בהשוואה ל- DNS-over-TLS?
hilltothesouth
2020-08-06 12:08:28 UTC
view on stackexchange narkive permalink

שמעתי את הטענה נגד DNS-over-HTTPS לפיה זה אמור להיות סיוט אבטחה עבור מגיני הרשת מכיוון שהוא מאפשר DNS מוצפן דרך יציאה 443, בהשוואה ל- DNS-over-TLS שעובר דרך יציאה 853.

אני לא מבין את הטיעון הזה מכיוון שכיצד קשה יותר לאתר ולחסום תעבורה זדונית ב- DoH מאשר נניח חיבור VPN דרך יציאה 443 או חיבור proxy דרך HTTPS על יציאה 443? אם אתה מגן רשת, ואתה מאפשר חיבורי VPN ופרוקסי צד שלישי ברשת שלך, מדוע ש- DNS over-HTTPS יהפוך את עבודתך לקשה יותר מכפי שהיא כבר, ומדוע DNS-over-TLS יהיה כך הרבה יותר טוב?

תוכל למצוא הסבר כלשהו בקטע [ביקורת DOH בוויקיפדיה] (https://en.wikipedia.org/wiki/DNS_over_HTTPS#Criticisms_and_implementation_considerations).זה בעיקר על כך שהסינון / חסימה של התנועה הרבה יותר קשה.זו בעיה מסוימת עבור ספקי אינטרנט (או חברות) שחייבים או רוצים לסנן / לחסום תעבורת רשת.
אני חושב שהבעיה העיקרית עם DoH מנקודת מבטו של מגן אינה סינון נתונים אלא צמצום הנראות בבקשות DNS.פירוש הדבר שיש להשתמש בשיטות פולשניות יותר (ויקרות) כמו פיקוח מנות עמוק או יירוט SSL.
@Marc רק המשפט הראשון קשור לשאלתי.אני מבין שלבקשות DNS מוצפנות קשה הרבה יותר לסנן ביחס לחסימת אתרים מסוימים עבור למשל בקרת הורים.מה שאני לא מבין זה איך אי איסור על DNS-over-HTTPS ימנע מדברים כמו גודולה לעבור רק לחיבור VPN או proxy מוצפן במקום חיבור DNS מוצפן על כל דבר זדוני שיעשו.כיצד קשה יותר לפקח ולנתח DNS מוצפן מאשר HTTPS מוצפן?
@SteffenUllrich זה בהנחה שהדאגה העיקרית שלך היא נראות לבקשות DNS.אבל אם הדאגה העיקרית שלך היא פשוט אבטחת הרשת, אז ...?על זה עוסקת השאלה שלי.אני יודע שזה מקשה על המעקב לאיזה אתרי אינטרנט / שרתים התקנים ברשת שלך מתחברים, אבל ניטור = / = אבטחה, ואבטחה נראית לי לא מושפעת.
@hilltothesouth: * "... אבל ניטור = / = אבטחה, ואבטחה נראית לי לא מושפעת." * - יש המון אבטחה שמבוססת על נראות ה- DNS, כמו חסימת דומיינים זדוניים ידועים, הגבלת הגישה לתחומים שלא נבחנו בעבר (כמו בשימושבפישינג) וכו '. פתרונות אבטחה כמו Cisco Umbrella מבוססים על ניטור וסינון מבוסס DNS מכיוון שמדובר בשיטה קלה דומה ופחות פולשנית.
@hilltothesouth שאלה זו הגיונית הרבה יותר.תודה על העריכה.
חָמֵשׁ תשובות:
Esa Jokinen
2020-08-06 12:56:31 UTC
view on stackexchange narkive permalink

שוב, הכל קשור למודל האיום!

טכנולוגיות הן רק טכנולוגיות וניתן להשתמש בהן לטוב ולרע. DNS מעל HTTPS (DoH) מתכוון לפתור את ה פרטיות החששות שיש ל- DNS לא מוצפן, ואילו DNSSEC יכול לפתור את ה שלמות חששות ללא צורך בהצפנה. יחד עם DNS מעל TLS (DoT), הם כולם נלחמים בתהום של מפעיל רשת זדונית שמרגל אחר תעבורת ה- DNS שלך או מזייף תגובות.

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

לא כל כך קל לאיתור

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

בהשוואה ל- DoH, DoT קל לחסום, מכיוון שיש לו יציאה ייעודית 853 (tcp&udp) לכל RFC 7858.

לקבלת תובנות מפורטות יותר בנושא אני ממליץ: Drew Hjelm: מחט וחציר חדש: זיהוי DNS באמצעות שימוש ב- HTTPS (מכון SANS 2019). יש לו גם כמה דוגמאות לבעיות האבטחה האמיתיות:

2.3. איומים ציבוריים מ- DNS מוצפן

ארגונים צריכים להתחיל להעריך את הסיכון הכרוך בפרוטוקול DoH מכיוון שתוקפים כבר החלו להשתמש ב- DoH כדי לחפש שרתי פיקוד ושליטה (C2). הדוגמה המוכרת ביותר ל- DoH כמנגנון aC2 הגיעה באפריל 2019 עם הדלת האחורית של גודלו (360 Netlab, 2019). גרסה חדשה יותר של הדלת האחורית של Godlua פועלת על Linux ו- Windows ומשתמשת בבקשת DoH כדי לתפוס חלק ממידע ה- C2 שלה.

דרך אחרת שתוקף יכול להשתמש ב- DoH בהתקפה היא להפעיל דף אינטרנט שהופנה מחדש כחלק מ קמפיין ספאם. חוקרים ב- MyOnlineSecurity (2019) מצאו מדגם שבו לקובץ מצורף לדוא"ל היה מחרוזת מקודדת aBase64 שתשאול את Google DoH עבור רשומת TXT. לרשומת TXT תהיה הפניה של JavaScript לדף אינטרנט זבל שכתובת זו משתנה לעתים קרובות. הוכחות הרעיון של DoH C2 זמינות לציבור, כלומר האיום של שחקנים זדוניים המשתמשים ב- DoH עשוי לגדול בקרוב.

הצפנת הנתונים שלך מעניקה לך פרטיות, אך ה- NSA שונא זאת כאשר הם אינם יכולים לראות את הודעות הפייסבוק שלך מכיוון שההצפנה הזו גורמת להם לא להיות מסוגלים לחטט בנתונים של הרעים (וגם שלך) כדי "להפוך את כולם לבטוחים יותר".
@esa-jokinen תודה על קישור העיתון הלבן של מכון SANS.עדיין לא קראתי את כל זה, אך נראה כי אפילו חוקרים אלה תוהים אם מלבד היציאה השונה הניתנת לחסימה בקלות, DoT בטוח יותר מאשר DoH.הפסקה הבאה אחרי אלה ששיתפת קובעת: "נכון לכתיבת שורות אלה, היה פחות סיכון שהוצג על ידי DoT כווקטור זדוני מאשר DoH. ראשית, חדשות חדשות אבטחת מידע לא דיווחו באופן נרחב על שימוש בתוכנות זדוניות מבוססות DoT באמצעות יציאת TCP 853 ... פעילות זדונית באמצעות DoT עלולהסיכון עתידי, אך האיום הנוכחי אינו גבוה. "
@JohnZhau: או NSA אוהבים את זה כש- HTTPS מונע מסוכנויות ביון אחרות לראות את אותם הודעות שכבר יש להן גישה בשרתי פייסבוק.;)
@hilltothesouth: כן.פשוט לא יכולתי לצטט את כל העיתון כאן.
"DoT בטוח יותר מ- DoH", HTTP מביא סט של נקודות תורפה משלו, טביעות אצבעות (ראה https://tools.ietf.org/html/rfc8484#section-8.2) וכו '. זו פשרה.באינטרנט טהור היפותטי לחלוטין ללא תוכנה או חומרה שבורים מסביב, DoT הגיוני יותר כפחות שכבות.עד שכמובן שתעבור להודעות DNS המקודדות JSON במקום "כמו על החוט של DNS / 53", מה שמביא לך יתרונות (או בעיות) אחרים בארץ HTTP שלא תהיה לך ב- DoT.
Lekensteyn
2020-08-07 15:46:18 UTC
view on stackexchange narkive permalink

שמעתי את הטענה נגד DNS-over-HTTPS כי זה אמור להיות סיוט אבטחה עבור מגיני הרשת מכיוון שהוא מאפשר DNS מוצפן דרך יציאה 443, בהשוואה ל- DNS-over-TLS שעובר דרך יציאה 853.

מגיני רשת אלה הם אולי סביבות ארגוניות המסתמכות על בדיקת DNS רגיל בכדי לאכוף מדיניות. בהנחה שהתקנים יחזרו ל- DNS בטקסט רגיל אם DoH / DoT אינם זמינים, מנהלי הרשת יכולים לחסום את יציאה 853 עם סיכון מועט מכיוון שהוא משמש רק את DoT. מצד שני, אם הם פשוט חוסמים את יציאת 443, אז כל אתרי ה- HTTPS יהפכו לבלתי זמינים.

באופן דומה, אם הם רואים שטף של תעבורת DoT, זה יכול להצביע על חריגה. אם מתרחשים כמה קפיצי תנועה דומים עם DoH, יתכן שלא ניתן יהיה להבחין ישירות בין HTTPS לתעבורת DoH.

באשר לשאלה מהכותרת:

מדוע DNS-over-HTTPS סיוט אבטחה כה גדול בהשוואה ל- DNS-over-TLS?

זה כנראה צריך להיות מנוסח כ"למה DNS-over-HTTPS נראה חזק > כסיוט ביטחוני בהשוואה ל- DNS-over-TLS? ". DoH ו- DoT די דומים ברמת פרוטוקול, בשני המקרים הודעות DNS מוצפנות. ראה גם את פוסט הבלוג שלי ב- Cloudflare המסביר הצפנת DNS שבו אני מתאר את פרטי הפרוטוקול הטכני, אפשרויות הפריסה והציפיות השונות מצד אנשים וארגונים.

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

DoH ו- DoT מעולים בהגנה על פרטיותם ושלמותן של שאילתות DNS בסביבות לא מהימנות כגון Wi-Fi בשדה התעופה או אפילו חטטנות / הפרעות מצד השלטון המקומי. אולם מכיוון שמדובר בטכנולוגיה מתפתחת, לא לכל פתרני ה- DNS הקיימים יש תמיכה בכך.

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

לסיום, אני לא חושב ש- DoH הוא כזה "סיוט ביטחוני" כנטען. רק שחלק מהארגונים מודאגים מאיבוד שליטה ב- DNS. בעבר היא נשלטה באופן מרכזי על ידי מערכת ההפעלה, אך מכיוון ש- DoH / DoT עדיין די חדש, אין תקן אמיתי להגדרת תצורה כל כך שליישומים רבים יש מנגנונים משלהם לעשות זאת. זה כנראה "הסיוט" שיש למנהלים מסוימים, המורכבות הנוספת שעוברים עליהם כדי להבטיח שמדיניות הסינון שלהם תוחל.

"זו כנראה הסיבה לדחיפה השלילית כנגד ספק שירותי האינטרנט והממשלות נגד DoH."הדחיפה היא גם ממשתמשים שאינם אוהבים כל סוג של תוכנה שמנסים להעמיד פנים שהיא יודעת טוב יותר מהמשתמש ופשוט לזרוק אותה בגרונה החלטה כלשהי (הגדרת DOH מקודדת, שרק לאט לאט התפתחה לבחירה בין 2 ולתהליך בחירה של אחריםמפעילים שפשוט משליכים אפילו תאימות DNSSEC ...).דפדפנים אחרים עשו את הגישה ההגיונית יותר של מעבר ל- DoH רק אם ידוע ששרת השמות המוגדר תומך בו (עם בעיות אחרות אז לגבי גילוי).
"רק שחלק מהארגונים מודאגים מאיבוד שליטה ב- DNS."השליטה פשוט עוברת מ- A ל- B, היא עדיין קיימת ועבור חלקם היא גרועה עוד יותר מכיוון ש- A מבוזרת (או יכולה להיות, כי המשתמשים בחרו) כאשר B, לפחות בהפעלה ראשונה, הוא מרכזי לחלוטין, מוסתר מהמשתמשים, וקשה לשינוי.הדפדפנים התחילו את המגמה הזו, אך יישומים אחרים יעשו את אותו הדבר, מה שעשוי להניב תפיסה עולמית מפוצלת, שבה תלוי ביישום תגיעו לשרתי שמות רקורסיביים אחרים לחלוטין, העלולים להוביל לתגובות שונות לחלוטין.
@PatrickMevzek אצטרך לחלוק על "A מבוזרת ואילו B ריכוזית לחלוטין."אם כבר, עכשיו הדברים מבוזרים מתמיד עם יישומים שיכולים לבטל את הגדרות מערכת ההפעלה בנפרד.
עובדות טהורות אף.לפני כן: כל אחד יכול להשתמש בכל DNS ובפועל לרוב ספק שירותי האינטרנט, כל כך מבוזר לחלוטין.כשפיירפוקס החלף בין DOH, כל הבקשות עוברות ל- IP יחיד, וזה מה שמכונה ריכוזיות.הפרוטוקול עצמו אינו משנה דבר, כל גרסה של DNS יכולה להיות מרוכזת / מבוזרת כרצון אחד.הבעיה היא כיצד הוצגה DoH בדפדפנים.באשר ל"יישומים שיכולים לבטל את הגדרות מערכת ההפעלה באופן אינדיבידואלי. "אני לא בטוח שזה תועלת של 100%, זה קצה כפול חרב.אבל אני מניח שזה הולך עם המגמה, כמו ש- QUIC נמצא ביישומים.
פריט אחד שמתעלמים ממנו לעתים קרובות הוא ש- DoH מנרמל את הרעיון של כל שאילתות ה- DNS, אפילו שאילתות שיכולות להישאר מקומיות לחלוטין (מטמון, רזולר מקומי וכו '), המועברות לספק מרחוק בזמן אמת.במידה מסוימת מדובר בטריטוריה שלא נחקרה - האם ספק זה, עם כל הנתונים הללו, יכול לבטל את האנונומיזציה של המשתמשים כעת או בעתיד?ואם כן, אין דרך לחזור מבלי לחסום HTTPS, לנעול מחשבים אישיים ו / או MITMing * כל * תעבורת HTTPS בנתב הקצה.מדובר בשחיקה של שליטה ברשת שעלולה להוביל לשחיקה גדולה בהרבה של הפרטיות בשלב כלשהו בעתיד.
הסיכון האמיתי כאן הוא ההומוגניות של המערכת האקולוגית באינטרנט בכללותה - חברות שניתן לטעון שכבר חלק גדול מדי מהאינטרנט משתמשות בזה כדי לדחוף את האג'נדה שלהן ולממש את עצמן, מה שמקשה עוד יותר על נכנסים חדשים באופן משמעותי.להתחרות במגזרים עוד יותר.
@PatrickMevzek שרת ה- DoH בפיירפוקס מעולם לא היה מקודד קשה, משתמשים תמיד הצליחו לשנות אותו באמצעות העדפת [`network.trr.uri`] (https://wiki.mozilla.org/Trusted_Recursive_Resolver).באשר לאפשרות ה"הגיונית יותר "של מעבר כאשר נראה שהפתרון המוגדר תומך בכך, זהו" המצב האופורטוניסטי "עליו כתבתי ב [פוסט זה] (https://blog.cloudflare.com/dns-encryption-explained/) ויש לו גם חסרונות.
שאילתות DNS רגילות של @madscientist159 מגיעות גם לספק מרוחק, DoH לא משנה את זה.אחסון במטמון של רשומות DNS המבוסס על ה- TTL שלהם זמין הן עבור DoH והן עבור DNS רגיל.DoH הוא רק תחבורה מוצפנת.אם יש לך אמון רב יותר ב- ISP שלך והם מיישמים את DoH, הגדר זאת בשום אופן.אך אם תפעיל את הרזולר הרקורסיבי בעצמך, תהפוך את עצמך לזיהוי יותר (פחות פרטיות).
"שרת ה- DoH ב- Firefox מעולם לא היה מקודד, המשתמשים תמיד הצליחו לשנות אותו באמצעות העדפת הרשת. Trr.uri."כן כן כמובן, אגדה נחמדה.מדוע שום אלמנט ממשק משתמש אז לשנות אותו?פשוט דרך להכריח אנשים לעשות משהו, עם מעט מאוד הסברים.זה פוגע בדברים לטווח הרחוק מכיוון שאנשים מתחילים לבלבל את הפרוטוקול (שיש בו מקרי שימוש, כמו גם חסרונותיו) מכל יישום / שימוש בו.זה גם גורם לו להיראות כמו ריכוזי ללא שום מטרה, בעוד שהוא, ברמת הפרוטוקול, לא יותר ריכוזי או מבוזר מאשר גרסאות.
"בשום אופן להגדיר את זה."... למעט בתוכנה גרועה שמאלצת אותך אחרת או הופכת את השינוי לקשה מאוד ונסתר.
"אבל אם תפעיל את הרזולר הרקורסיבי שלך, אתה בעצם יהפוך את עצמך לזיהוי יותר (פחות פרטיות)."לא נכון בכלל ... הפותר יכול להעביר לכל אחד אחר, ויכול להיות בעל רזולוציה חכמה יותר על ידי פיזור העומס בין מספר שרתים רקורסיביים אחרים.רק ריכוז לשרת אחד אינו רווח מיידי של 100% בפרטיות.זה עוזר בדרך, ויוצר בעיה אצל אחר.זה לא כשלעצמו דרך חסינת מעצורים להחזיר את הפרטיות.
@patrick-mevzek בדיוק!ואותו פותר יכול לסרב לענות על שאילתות לגבי אתרים מסוימים, שניהם משמשים רשת ביטחון כנגד תקלות ומגבילים את האחריות החוקית כלפי המפעיל (כן, משתמשים נחושים מספיק יכולים לעקוף זאת, אך בשלב זה פעולות כאלה ככל הנראה ייפלו תחת מחשב לא מורשה.השתמש בחוקים וכו 'אם זה אי פעם הגיע לתביעה משפטית).עם DoH ברשתות ארגוניות, אתה מקבל את הסיכון להיות שותף לפעולה בלתי חוקית כלשהי של עובד, לאסור את BYOD לחלוטין, או MITM HTTPS בכוח.ברשתות אישיות אתה עדיין פחות אנונימי לספק ה- DoH.
R.. GitHub STOP HELPING ICE
2020-08-07 06:53:48 UTC
view on stackexchange narkive permalink

אתה צודק שהטיעון שלהם לא הגיוני, אבל הוא לא אמור לעשות זאת. זה אמור רק להוריד את ה- DNS over-HTTPS, שזו הגישה הממריאה בפועל מכיוון שפחות סיכוי להיחסם מ זבל של תיבת הביניים הקיימת . בהנחה שהשאילתות הן לשרתים ציבוריים פתוחים ידועים, קל באותה מידה להוסיף כללים חדשים כדי לחסום אותם ללא קשר לפרוטוקול המשמש, אך האנשים שנלחמים נגד DNS-over-HTTPS נלחמים נגד ה נורמליזציה של שאילתות DNS הן פרטיות; ברגע שמשיג מסה קריטית כברירת מחדל בדפדפנים ויישומי לקוח, חסימתה פשוט תשבור הכל, מה שהופך אותה לחסימה כמעט.

owenthewizard
2020-08-08 05:16:53 UTC
view on stackexchange narkive permalink

נקודה שהתשובות האחרות נגעה בהן רק בקלילות היא שהמשתמש עצמו אולי ירצה לחסום שאילתות DNS מסוימות. לדוגמה, אני משתמש ב- Pi-Hole ברשת הביתית שלי כדי לחסום שאילתות DNS הידועות כמגישות פרסומות. למרות שאילתות DNS יוצאות חסומות, מכשיר עשוי להשתמש ב- DoH כדי לעקוף זאת.

ל- DoH באמת אין שום קשר לשאלה אם אתה יכול לחסום מודעות.אם האפליקציה שמשרתת אותם אכן מכבדת את העדפות ה- DNS שלך, אתה יכול להגדיר שרת DoH שחוסם מודעות, ואם לא, זה יכול באותה קלות להקשיב את כתובות ה- IP במקום להשתמש בכלל ב- DNS.
@JosephSible-ReinstateMonica, תשובה זו חסרה פירוט.מה שאני מאמין שהם מגיעים אליו הוא שחסימת יציאה 53 TCP / UDP בהיקף מאלצת אחד להשתמש בשרת ה- DNS הפנימי.מכיוון ש- TCP443 פתוח באופן אוניברסלי, DoH יכול לעקוף שליטה זו.
phbits
2020-08-09 02:20:25 UTC
view on stackexchange narkive permalink

באופן מסורתי, חסימה / התרת שירותים התרחשה בשכבת התחבורה. ה- DNS הוגבל לשימוש ביציאה 53 ב- TCP / UDP. תעבורת רשת תשתמש ב- TCP 80/443. כן הלאה וכן הלאה. זה מקל על ניהול הרשת מאחר ושירותים מופרדים באמצעות פרוטוקולים ויציאות. DNS-over-TLS שומר על מנהל תכנון זה מאחר והשירות משתמש ביציאת TCP 853.

כדוגמה, שקול את המופע הנפוץ של אילוץ שימוש בשרת ה- DNS הפנימי. ניתן להשיג זאת על ידי יישום ACL של נתב / חומת אש כדלקמן: 

  block drop allpass in proto udp from 10.1.1.0/24 to $ internal_dns port 53pass in proto tcp from 10.1 .1.0 / 24 ליציאת $ internal_dns 53 עוברים ב- proto tcp מ- 10.1.1.0/24 ליציאת $ internal_dns 853

עכשיו יש לנו כל מיני תעבורה שחוצה את TCP 443 בין אם זה להיות VPN SSL, גלישה באינטרנט ועכשיו DNS over-HTTPS (DoH) רק כדי שם כמה. חסימת תנועה זו דורשת ציוד מתוחכם יותר מכיוון שהתנועה מוצפנת באמצעות HTTPS ומצטרפת לתעבורת HTTPS אחרת ביציאת TCP 443. על המכשיר להיות מסוגל לזהות את DoH באמצעות חתימה Application Layer אשר זמינה רק במומחים מיוחדים. צִיוּד. ציוד כזה לא יכול להיות זול עבור ארגונים קטנים יותר, או שהם חסרים רוחב פס לניהולו.

ניתן לראות כיצד DNS-over-HTTPS הוא בעיה הרבה יותר קשה ואז לאפשר או לחסום פרוטוקול ויציאה. שילוב כמו DNS-over-TLS. זהו מעבר מתכנון רשת מסורתי לכזה הדורש נראות רבה יותר לכל התעבורה המוצפנת השונה שעוברת על יציאת TCP 443.



ⓘ
שאלה ותשובה זו תורגמה אוטומטית מהשפה האנגלית.התוכן המקורי זמין ב- stackexchange, ואנו מודים לו על רישיון cc by-sa 4.0 עליו הוא מופץ.
Loading...