Confessions Of A Dangerous Mind

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

נושא זה היווה בעייה כלל עולמית במסחר אלקטרוני ( eCommerce ) ולכן הדרך שנראתה הכי נכונה לטפל בנושא הייתה באמצעות אלמנטים של הצפנה. היום לא תראו אתר מסחר אחד שמכבד את עצמו , שלא יפרסם ( בתקנון או בתמונה בעמוד הראשי ) שהוא מצפין את החלפת הפרטים בSSL , ושהמידע מעורבל. חלק מחברות המסחר אף טרחו להסביר שמסדי הנתונים מופרדים מאחורי הקלעים באמצעות Firewalls ביניהם ולכן אפילו יותר מוגנים.

אז ראשית קצת טכני, SSL הוא אכן פרוטוקול הצפנה יעיל. הוא מאפשר החלפת מפתחות בין שני
צדדים שהם Client\Server ועל ידי יצירת Session וירטואלי ( מאחר ובHTTP1.0 או ב1.1 לא קיים אלמנט הSESSION ) לערבל ולהצפין את המידע העובר בין הCLIENT לSERVER ולהיפך, ועל ידי כך למעשה ליצור טרנזאקציה בטוחה.

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

הבעיה היא ...
95% מהאתרים בארץ ובעולם אשר מבצעים טרנזאקציות של מידע שמור ואישי , כולל אתרי מסחר אלקטרוני , בנקים , שירותים פרטיים וכדומה , אינם מצפינים את החלפת שם המשתמש והסיסמה.
מה שנוצר בתהליך זה הוא שלמרות שאת המידע הרגיש שלי אי אפשר לגנוב On-The-Fly על ידי
Sniffing או Hijacking ( יש לי סייגים פה ) אבל ניתן לגנוב את שם המשתמש והסיסמה שלי שמשודרים PLAINTEXT עוד לפני שהעברתי פרט אחד !!! אם לאותו CRACKER יש את השם משתמש והסיסמה שלי , הוא לא צריך לחפש את האשראי שלי , כי הפרטים כבר מולו !!!.

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

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


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

Labels: architecture, ecommerce, issues, ssl

Posted by barry at 3:08 PM | Link | Comments

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

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

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

הפתרון המוכר ביותר לגישה מוצפנת ( ולכן לא אדבר כאן על PPTP ועל יישומים שלו למרות שחלקם אף כוללים הצפנה ) יהיה להשתמש בפרוטוקול אשר יעטוף את התצורה הרגילה לגישה בפרוטוקול מוצפן ( למשל RDP OVER SSH ) ובכך יאפשר גישה בטוחה. הדרך המוכרת ביותר לבצע זאת היא על ידי IPSec , הצפנת התווך בין שתי נקודות או בין נקודה לרשת.

בשנים האחרונות אנו רואים מספר אלמנטים של שימוש בSSL לצורך הקמת אותו תווך מוצפן, מדובר למעשה בשימוש בSSLv3 ( שהוא בעצם TLS המוגדר בRFC2246 ). למי שלא מכיר - SSL עובד בשכבת הSESSION והומצא על ידי NETSCAPE לפני מספר שנים שלא זכור לי לנקודה זו. ובכן המטרה בשכבת הSESSION הייתה לאפשר לעבוד עם SESSION COOKIES בדפדפנים ( שכן פרוטוקול HTTP אינו תומך בSESSION כלל ) . ובכן , על מנת לאפשר לאפליקציות רשתיות לרוץ על התשתית המוצפנת , עלינו לרדת כמובן שכבה, לכן הומצא הTLS שהוא Transport Layer Security שמאפשר לנו להצפין בשכבה הרביעית .

על ידי כך שהSSL מאפשר כעת לעבוד ברמה הרשתית ולא רק ברמת הWEB BROWSER , אנו יכולים כעת לקיים קישורים מרוחקים מאובטחים ( אפשר להתווכח על זה ) אשר מאפשרים גישה ללא הצורך בהתקנת תוכנת קצה ( לכל מחשב סטנדרטי יש היום דפדפן אשר תומך בSSL ) ולכן מוריד את הOVERHEAD האדיר שפתרונות הACCESS בדרך כלל יוצרים על מחלקות הIT השונות.
למעשה , משתמש מרוחק יכול להתחבר מכל מקום בעולם , ללא התקנה של כל תוכנה , ולהתחבר לארגון בצורה בטוחה ולעבוד מרחוק.

ישנו נושא אחד שנפגע עצם השימוש בSSL כיום, שהוא תצורת האימפלמנטציה של ההצפנה. אך זה נושא שמאוד מותנה בצורך ובאופן השימוש, שכן איני רואה לנכון ארגון יוצר קישור בין אתרים במיקומים מרוחקים על ידי קישור בהצפנה פחותה מAES256 ( למרות שקיימות כבר אימפלמנטציות של AES OVER TLS ). אך יכול להתאים בצורה מופלאה וקלה ביותר ליישום לצורך מתן מענה לעבודה מרחוק בסביבות אשר מוגדרות סביבות מזוהמות - אינטרנט קפה הוא דוגמא מצויינת לנקודת גישה אשר כל מזיק , וירוס וקוד זדוני פשוט מחכים בה.

מובן שלכל פתרון יש היתרונות והחסרונות שלו , ומאוד תלוי איך אותו VENDOR בוחר ליישם את פתרון הSSL-VPN שלו. מנסיוני אין פתרון אחד שמתאים לכל ארגון , בסביבות מונחות יצרן אחד ספציפי יתכן שיתאים פיתרון אחד , בעוד לארגון אחר אשר דורש ניקוי בAV לתשתית הSSL שלו יתאים פתרון אחר. ישנם פתרונות המהווים PROXY מלא בין נקודת הגישה לאתר עצמו, ישנם פתרונות אשר מסוגלים לבצע בדיקות UTM וניקוי של מזיקים מהתווך המוצפן, וישנם אף פתרונות שמקימים סביבה נפרדת חד פעמית מוצפנת אשר אינה יושבת על הIO אלא בSANDBOX ייעודי. אין כאן כללים מנחים ויש לשקול כל פתרון לגופו.

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


** שימו לב , ישנו המשך שעיקרו טכני בתגובות למאמר זה.

Labels: access, ssl, technology, vpn

Posted by barry at 10:10 AM | Link | Comments