יום שבת, דצמבר 03, 2016

Office365 mount forbidden

לצערי לא ניתן יותר להשתמש ב davfs2 בשביל לעגון תוכן משותף שיושב על office365 (שיתוף ע"ג sharepoint). גם תוכנות קוד פתוח דוגמת cyberduck נכשלות כשלון חרוץ , קונקי וחבריו לא הצליחו לתת לי פתרון סביר ללא מאמץ.

בדר"כ כאשר יוצא לי לעבוד עם מוצרי מייקרוספט אירגוניים, הם בדרך משתפים דברים ע"ג sharepoint או cifs, (יש גם פתרונות אחרים אבל באלא הכי נתקלתי).

מניסיון העבר sharepoint בדר"כ משתמש בפרוטוקול webdav[s] וזה פשוט עובד מהקופסא, גם בויינדוס וגם בדביאן/רד האט.

יש מערכות שאתה צריך להזדהות פשוט ב http basic באחרות קרברוס ויש כאלה שדורשים OAuth. אבל ככל זה פשוט עובד. 

בעבר הייתי משתמש בcadaver ו mount.davfs2 בשביל העיגון :

עבור webdav אני משתמש ב davf2 ובשביל לעגן את החומר המשותף של VSA תחת 9.17.232.196 מספיק לשמור את פרטי ההתחברות ב  ~/.davf2/secrets כמו :

http://9.17.232.196/sites/VSA/ schenzel myPaSSwoRd

ואז פשוט ב cadaver או mount.

הפעם הדומיין שלי הוא example תחת sharepoint.com:

וניסיתי לשמור את הפרטים בצורה של  :
https://example.sharepoint.com/sites/VSA/ schenzel myPaSSwoRd

וזה נכשל עם שגיאה 403, גם ניסיון גישה באמצעות cadaver או אפילו גישה ל webdavs://example.sharepoint.com/sites/VSA בקונקורר נותן וריאציות של 403.

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

x-msdavext_error: 917656;
 Access+denied.+Before+opening+files+in+this+location%%2c+you+must+first+browse+to+the+web+site

הפתרון ? להתחבר ל https://example.sharepoint.com  באמצעות משהוא שיוכל לשתף עוגיות עם התוכנה איתה אתם מתחברים לרכיב (נגיד konqueror).

במקרה של konqueror מספיק פשוט להתחבר ל https://example.sharepoint.com ואז ניתן לגשת לכל הדברים המשותפים באמצעות webdavs לדוגמא ל:
webdavs://example.sharepoint.com/sites/VSA 

בגלל שמדובר על עוגיות והדומיין של העוגייה הוא example.sharepoint.com אז ניתן להשתמש בעוגיה עבור כל האתרים המשותפים (שנמצאים תחת sites/SITE_NAME). 

התיקיות שמעניינת אותי  בדר"כ זה (בהנחה שקוראים לsite כ VSA) :

webdavs://example.sharepoint.com/sites/VSA/Shared%20Documents/

במידה ויש לנו notebooks או תיקיות (בממשק השרפויינט) זה יהיה סך הכל תיקייה עם קבצים שאפשר להעתיק מקומית.

יום שלישי, אוקטובר 18, 2016

WISPr v1

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

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

WISPr תוכנן ע"י ה Wi-Fi Alliance והוא דרך לבצע פעולות AAA בשביל לאפשר נדידה (Roaming)  אצל ספקי תשתית על בסיס שירותים אלחוטיים (Wireless Internet Service Providers). כאשר אנו מגיעים לספק שיש לו חוזה התקשרות עם ספק האם שלנו אנו נוכל להתחבר אליו גם ללא חשבון (נדידה ב WiFi).


מוגדרים מספר שלבים בתהליך -

הזדהות משתמש הקצה. 
הזדהות הנקודה החמה (hotspot) אל מול ה שירות הזיהוי (Authentication ו Accounting)
התקשרות בין שירותי הזיהוי דרך יישות ניוד (roaming intermediary authntication and Accounting Server) אל ספקי התשתית.

למשתמש הקצה יש חוזה עם ספק התשתית , ספק זה יחייב את הלקוח ע"י חישוב השימוש שבוצע וזוהה ע"י שירות הזיהויי.


אם זה מזכיר לכם את אחד הספקים הגדולים בעולם שנקרא ipass אתם צודקים כי זו אחת הטכנולוגיות שהם משתמשים בהן, דוגמאות שאנשי הקצה יכולים להכיר זה skype wifi או ספקי תקשורת בהם הלקוחות נותנים חלק מרוחב הפס שלהם לרשתות המכילות את המילה Free Wi-Fi - אלו הם פשוט ספקי תקשורת שמספקים  שימוש נוסף באותו הספק או בשיטה דומה לספק הזה. אחד מהמשתמשים המוכרים למשתמשי הקצה אף מכיל התייחסות מפורשת לipass בתוך ה apk שלו.

בעת התקנה אפליקיית הקצה מותקנת חותמת להזדהות (certificate), ובסיס נתונים שמכיל רשתות אליהם מותר להתחבר.


תהליך ההזדהות -

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

אם בתוכן שחוזר קיים WISPr-xml-tag הזדהות ממשיכה אחרת עוצרת,
תוכן לדוגמא:

<HTML> 
<!--
    <?xml version=”1.0” encoding=”UTF-8”?>
    <WISPAccessGatewayParam xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
      xsi:noNamespaceSchemaLocation=”http://www.shekercolshehu.com/WISPAccessGatewayParam.xsd”>
      <Redirect>
        <AccessProcedure>1.0</AccessProcedure>
        <AccessLocation>Totaly not going to rip you off Network</AccessLocation>
        <LocationName>Totaly not going to rip you off</LocationName>
        <LoginURL>https://shekercolshehu.com/login</LoginURL>
        <MessageType>100</MessageType>
        <ResponseCode>0</ResponseCode>
      </Redirect>
    </WISPAccessGatewayParam>
--> 
</HTML>

לקוח הקצה קורא את תוכן המידע שהתקבל (זו אחת הסיבות למה libxml2.so קיים באפליקציית bezeq free wifi), ושולח בקשת חיבור ל LoginURL באמצעות POST ושימוש בחותמת שהותקנה.

זו בדיוק הצורה בה מכשירי הios יכלו להתחבר לAT&T בלי שום בעייה (כי attwifi הוא אחד מהספקי שלקוח ה wispr של אפל עובד איתו כברירת מחדל).

דוגמה לראות מה נקבל תחת שירות כזה היא (הU-A משחק תפקיד חשוב) הכתובת יכולה להיות כל כתובת בשביל לגלות את ההפניה:

$ curl -L -i -H "User-Agent: CaptiveNetworkSupport/1.0 wispr" www.google.com

כתוצאה נקבל את דף ה wispr במקרה שבאמצעותו יש להתחבר אבל אם נקבל באמת את התוכן של www.google.com זה אומר שאין שום wispr בדרך.

WISPr גם מזכיר את האפשרויות האחרות לביצוע הזדהות מול השירות כמו 801.11 (wpa_supplicant)

יום שני, אוקטובר 17, 2016

מאפייני מיקום

כאשר אנו עובדים על תשתיות הרשת פעמים רבות אנו עובדים על נתוני המיקום של המשתמשים בשביל לאפשר שירותי IMS ובשביל לספק שירותים מבוססי מיקום. אחת מדרישות הבסיס היא לאפשר לזהות ולשלוח מאפייני מיקום במקרי חירום  7852.

את נתוני המיקום ניתן לקבל באמצעות בקשת HTTP[s] משרת ה Location Server (LS). נתוני המיקום מתקבלים גם מלקוח הקצה וגם מרשת הסלולאר עצמה.

הממשקים מוגדרים גם ברמת ה TS וגם באמצעות RFCים לדוגמה 6753 (HELD)

קיימים שני פלטים פופלארים.

פלט בינארי בו אנו מקבלים חבילה עם מספר בייתים ובחבילה יש את המיקום ומאפיין המיקום.
בפורמט זה קיימים מספר אפשרויות מיקום :

  • Ellipsoid Poin;
  • Ellipsoid point with uncertainty circle
  • Ellipsoid point with uncertainty ellipse
  • Polygon
  • Ellipsoid point with altitude
  • Ellipsoid point with altitude and uncertainty ellipsoid
  • Ellipsoid Arc
ב 23.032 TS הסוג מקודד ע"י הפורמט בו ה4 הבייטים העליונים ( 8,7,6,5) בבייט הראשון מאפיינים את סוג הצורה :
Bits
4 3 2 1 
0 0 0 0 Ellipsoid Point 
0 0 0 1 Ellipsoid point with uncertainty Circle 
0 0 1 1 Ellipsoid point with uncertainty Ellipse 
0 1 0 1 Polygon 
1 0 0 0 Ellipsoid point with altitude 
1 0 0 1 Ellipsoid point with altitude and uncertainty Ellipsoid 
1 0 1 0 Ellipsoid Arc 

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

כאשר עובדים ב3G וGSM הדבר פשוט, המידע מתקבל דרך פעולות location update ושמירת המיקום בו בוצעה פעולה.

טווחי  האיכון  הם בערך כך :

מבוסס רשת האיכון הוא על בסיס  ה 300 מטר  (תלויי בפריסה ובציוד) , ה 300 מטר מגיע מדרישת ה FCC.
מבוסס מכשיר יכול להיות ברמת המטרים הבודדים.


פלט XMLי, מאופיין כ PIDF-LO.

בחלק משירותי ה WiFi יכולים לשלוח PIDF-LO (מהנתב עצמו) לפי גילוי משתמש, PIDF-LO למחשב שהזדהה כ USER-PC עבור המשתמש user יכול להיות מיוצג כך.



<presence entity="pres:user@subdomain.domain.com" xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:gml="http://www.opengis.net/gml" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns="urn:ietf:params:xml:ns:pidf"> <dm:device id="USER-PC"> <gp:geopriv> <gp:location-info> <gml:point srsname="urn:ogc:def:crs:EPSG::4326"> <gml:pos>32.86726 -97.16054</gml:pos> </gml:point> <cl:civicaddress> <cl:flr>2</cl:flr> </cl:civicaddress> </gp:location-info> <gp:usage-rules> <gp:method>Wiremap</gp:method> </gp:usage-rules></gp:geopriv> <dm:deviceid>mac:123456789012</dm:deviceid> <dm:timestamp>2016-10-01T20:57:29Z</dm:timestamp> </dm:device> </presence>

אבל איך זה עובד אם אנחנו לא מסתמכים על הרשת ואין לנו רכיבי GPS או GSM (במקרה שלVoWiFi  למשל).

כשאנו עובדים ב data נקי, וה UE שלנו הוא למשל מחשב המערכות מתבססות על מספר לקוחות.

לקוח ה DHCP שלנו יאפשר שימוש ב4776 .

בנוסף כאשר ה UE זז הרבה או שאנחנו לא יכולים לסמוך על לקוח ה dhcp שיעשה את העבודה אנו משתמשים ב 6442 , ובלקוחות LIS/LoST/held בשביל לקבל מאפייני מיקום מצד שלישי.

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

בצורה כזאת לקוח הSIP שלנו ישלח ויוסיף את מאפייני המיקום שלנו ע"י שימוש ב PIDF-LO

INVITE sips:bob@biloxi.example.com SIP/2.0
   Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9
   Max-Forwards: 70
   To: Bob <sips:bob@biloxi.example.com>
   From: Alice <sips:user@atlanta.example.com>;tag=9fxced76sl
   Call-ID: 3848276298220188511@atlanta.example.com
   Geolocation: <cid:target123@atlanta.example.com>
   Geolocation-Routing: no
   Accept: application/sdp, application/pidf+xml
   CSeq: 31862 INVITE
   Contact: <sips:user@atlanta.example.com>
   Content-Type: multipart/mixed; boundary=boundary1
   Content-Length: ...

   --boundary1

   Content-Type: application/sdp

   ...Session Description Protocol (SDP) goes here

   --boundary1

   Content-Type: application/pidf+xml
   Content-ID: <target123@atlanta.example.com>
   <?xml version="1.0" encoding="UTF-8"?>
       <presence
          xmlns="urn:ietf:params:xml:ns:pidf"
          xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
          xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
          xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
          xmlns:gml="http://www.opengis.net/gml"
          xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
          entity="pres:user@atlanta.example.com">
        <dm:device id="target123-1">
          <gp:geopriv>
            <gp:location-info>
              <gml:location>
                <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
                  <gml:pos>32.86726 -97.16054</gml:pos>
                </gml:Point>
             </gml:location>
            </gp:location-info>
            <gp:usage-rules>
              <gbp:retransmission-allowed>false
              </gbp:retransmission-allowed>
              <gbp:retention-expiry>2010-11-14T20:00:00Z
              </gbp:retention-expiry>
            </gp:usage-rules>
            <gp:method>802.11</gp:method>
          </gp:geopriv>
          <dm:deviceID>mac:1234567890ab</dm:deviceID>
          <dm:timestamp>2010-11-04T20:57:29Z</dm:timestamp>
        </dm:device>
      </presence>
   --boundary1--

מערכת יחיסית פופלארית מבצעת זאת כבר המון זמן, היא lync.

מיקום ב isc-dhcp-server

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

יש מספר RFCים שמתארים איך צריך לשלוח מאפיייני civic בבקשות DHCP.

העיקריים הם  :

4776
3825
6225
geopriv-dhcp-lbyr ביחד עם  dhcp-lci-option-03
held 


ב isc-dhcp-server בשביל להפעיל את העברת המידע צריך לאשר את הבקשה ברמת השרת לדוגמה עבור 4776 :

option unknown-99 code 99 = string;
option unknown-99 00:55:53:01:02:49:44:03:06:4D:6F:73:63:6F:77;
הקידוד לפורמט לפי RFC 4776.

את המיקום אפשר להגדיר פר שרת , או אפילו ברמת הsubnet. כמובן שבמקרה שאנו מספקים גישה ע"ג wifi צריך לתמוך ב 6224 ובגישה ל HELD ועדיפות שיהיה לקוח נוסף שיוכל לעדכן מיקום.

בשביל לדרוש לבקש את השדה יש להוסיף ב /etc/dhcp/dhclient.conf את הערך המתאים לפי השם הקנוני או unknown-code כאשר הcode הוא הערך מה RFC לדוגמה : unknown-99 (או geoconf-civic אם נתמך) תחת request או also request.

משום מה לא הצלחתי לראות למה unknown-123  ו 144 לא עבד (פשוט לא נשלח דרך הלקוח).

יום ראשון, אוקטובר 16, 2016

Wi-Fi calling

אז מה זה Wi-Fi Calling ולמה לנו כאנשי תוכנה חופשית זה כה חשוב  ?

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


הרעיון אומר שרכיב התקשורת שלכם (UE) מתחבר לרשת הוי-פי ומשתמש בה כרכיב גישת הרדיו שלה. הדבר מאפשר למכשירי הקצה לקבל תמיכה ברכבות , תעלות, בנייני משרדים וכל מיני מקומות בהם כיסוי הרדיו הרגיל מתקשה ודורש התקנת רכיבים אחרים (GSM-R ברכבות , משדרים מיוחדים בנקודות גישה וכו').

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

הדבר היחיד שאינו ממוש כמו שצריך ברכיבי הסלולאר הוא לקוח ה ipsec שיתאים בצורה טובה לדרישות ה VoWiFi.

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


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

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

אז איך זה עובד ?

לרעיון שימוש ב WiFi כרכיב התעבורה היו מספר גילגולים, הנושא הוצג גם ע"י GSMA וגם קיימים RFCים בדבר.

בגרסאות הישנות של הפתרון (לדוגמה ב WISPr) היו מגדירים שהטלפון שלכם יתחבר לרשתות בהם ה SSID הוא קבוע מראש (לדוגמה T-Mobile או tmobile) ואז מבצעים אימות EAP-SIM ומתקשרים ע"י SIP-IMS.

לאחר מספר גילגולים עברו לשימוש של גילוי דינאמי וקבלת הגדרות בזמן אמת ואז חיבור באמצעות רכיבי ה SIP ישירות לשרת (ספק השירות).שימוש בשירותי XCAP ועידכון מאפייני שיחה ע"י פעולות SIP.

ה RFCים מדברים על שלושה גישות :

גישת ה Trusted - בה אנו סומכים על הרשת המארחת (שלנו ), במצב כזה חברת השירות היא בעלת תשתיות ה AP. היא מבצעת את האימות קרוב לנתבים (היא גם יכולה לספק שירותי ANDSQ בשביל לגרום למערכת להתחבר בצורה פשוטה יותר).


                                                             +-------+
                                                             |  IMS  |
                                                             | Core  |
            +-------------+              +-----------+       +-------+
            |             |              |           |           |
            | +--------+  | Flow mapped  |           |           |
            | |IMS APN |  | to VMAC-01   |           |       +-------+
            | |        +-----------------+           |       |IMS APN|
            | |Client  |  |              |           +-------+ P-GW  |
            | +--------+  |              |           |       +-------+
            |             |              |           |
            |             |              |Release 12 |
            |             |              |  TWAG     |
            |             |              |           |       +-------+
            |             |              |           |       |Default|
            |             |              |           +-------+ APN   |
            | +--------+  | Flow mapped  |           |       | P-GW  |
            | |Default |  | to VMAC-02   |           |       +-------+
            | | APN    +-----------------+           |           |
            | |Client  |  |              |           |           |
            | +--------+  |              |           |           |
            +-------------+              +-----------+           |
                                                               XXXXXX
                                                             XX     XXX
                                                            XX        XX
                                                           X           X
                                                          X            X
                                                          X Internet   X
                                                          X            X
                                                          X           XX
                                                           X         XX
                                                            XX    XXXX
                                                             XXXXXX

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

      +--------------+            +----------+          +-------+
      | +----------+ |  IMS-APN   |          |          |       |
      | |    SWu   | |  Traffic   |          |          |       |
      | |  Client  +------------------------------------+       |
      | |          | | Other APN  |          |          | ePDG  |
      | |          | |  traffic   |          |          |       |
      | |          +------------------------------------+       |
      | |          | |            |          |          +-------+
      | +----------+ |            |          |            |  |
      |              |            |          |         S2b|  |S2b
      |     UE       |            |  WLAN    |            |  +---+
      |              |            | Access   |            |      |
      | +----------+ |  LBO       |          |    +-------+   +-------+
      | | Native   | |  Traffic   |          |    |IMS APN|   | Other |
      | |          | |            |          |    |  PGW  |   |  APN  |
      | | Client   +-------------------+     |    |       |   |  PGW  |
      | |          | |            |    |     |    +-------+   +-------+
      | +----------+ |            |    |     |         |          |
      +--------------+            +----------+         |          |
                                       |               |          |
                                       |           +-------+   +-------+
                                       |           |  IMS  |   |  App  |
                                       |           |       |   | Server|
                                       v           +-------+   +-------+


וגישה היברידת המשלבת את שני הדברים:

                                                  +------+   +---------+
                                                  | IMS  |   |  Other  |
                                                  | Core |   |Services |
                                                  +------+   +---------+
                                                     |           |
                                                  +------+   +-------+
       +--------------+      +-----------+        |IMS   |   | Other |
       | +----------+ |      |           |        |P-GW  |   | P-GW  |
       | |    SWu   | |      | +-------+ |        +------+   +-------+
       | |  Client  | |      | |SIPTO  | |           |           |
       | |          | |      | ++NAT   | |           |  +--------+
       | +----------+ |      | +-------+ |           |  |
       |              |      |           |        +------+
       |     UE       +------+   TWAG    |  S2b   | ePDG |
       |              |      |           +--------+      |
       | +----------+ |      |           |        +------+
       | | Native   | |      |           |
       | | Client   | |      |           |
       | |          | |      |           |  S2a   +-------+
       | +----------+ |      |           +--------+Default|
       +--------------+      +-----------+        | PGW   |
                                                  +-------+
                                                    |
                                                    |
                                                    +
                                                 XXXXXXXX
                                                XX      XX
                                                X        X
                                                XInternetX
                                                X        X
                                                XX      XX
                                                 XXXXXXX


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

בצורה כזאת חברות שמספקות MVNO (או ספקי תקשורת רגילים) יכולות להצהיר על הרשת שלהם תחת כתובות DNS, שמות השירותים מוגדרים מראש (כמו במקרה הENUM ).

GSMA הכריז על מספר שירותים אליהם ניתן להתחבר בשביל לקבל גישה לשירותים :

http://epdg.epc.mnc$(MNC).mcc$(MCC).pub.3gppnetwork.org

http://ss.epdg.epc.mnc$(MNC).mcc$(MCC).pub.3gppnetwork.org

http://rcs.mnc$(MNC).mcc$(MCC).pub.3gppnetwork.org

http://mnc$(MNC).mcc$(MCC).pub.3gppnetwork.org

http://bsf.ims.mnc$(MNC).mcc$(MCC).pub.3gppnetwork.org

http://xcap.ims.mnc$(MNC).mcc$(MCC).pub.3gppnetwork.org

http://andsf.ims.mnc$(MNC).mcc$(MCC).pub.3gppnetwork.org


כל אחת מהכתובת בעת משמעות משלה שמאפשרת שימוש במשאבים נוספים.

במהלך החיבור יקבל את המאפיינים של ה Evolved Packet Data Gateway  (ePDG)  שאיתם צריך להתחבר.

במקרה של רשת שאינה בטוחה נפתח ערוץ ipsec :

לקוח הקצה יפתח ערוץ IPSEC/IKEv2 ( 5996 ו 3GPP TS 33.402)   לשרת בשביל שנוכל להשתמש במשאבי הרשת. ההזדהות (NAI) תהיה במבנה של IMSI@Realm (או מזהה מכשיר תחת realm) וזה ימולא תחת ה IDi בשדה ה IDr נמלא את ה APN שצריך להתחבר בתוך ה ePDG .

לאחר שיבוצע אימות כלפי ה ePDG ונקבל אישור לפתיחת session לאחר מכן לקוח ה SIP-IMS שלנו יבצע invite לקבל שירות.

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

במקרה של רשת מאובטחת לא מקימים תעלה, האימות מתבצע קרוב ל חיבור ל AP ע"י אחד מאפשרויות האימות מבוססי ה EAP, לבסוף לקוח הסיפ יבצע register בשביל להתחיל להשתמש במשאבי הרשת.


הכתובת config.rcs.pub.3gppnetwork.org מאפשר ממשק HTTP לקבל את מאפייני החיבור (זה rcs רגיל) , xcap הוא אותו ה xcap שאנו משתמשים ברכיבי ה SIP כאשר אנו מדברים עם רשתות LTE ו 3G. לצערי הרב ktp ו linphone לא מציגים דרך קלה לעבוד עם xcap.


בצד הלקוח -

בשביל שנוכל להשתמש באפשרויות האלה אנו נצטרך לקוח wpa_suppliant עדכני , לקוח SIP ולקוח ipsec איתו נוכל להתחבר לרשת רכיב חומרה שיודע לקרוא כרטיסי SIM או פשוט מכשיר סלולאר שיודע לתמוך ב WiFi Calling ו LTE.

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

אני מאמין ש linphone ידע להתמודד טוב עם SIP-IMS  ב VoWiFi עם המגבלות הבאות :

אני חושב שהתמיכה ב SMS over IP תהיה לוקה בחסר (יש תמיכה ב 3428 ונראה לי גם ב 4976 אבל לא בטוח שיש תמיכה בכל מה שתחת TS.2431) , הודעות חירום לא יעבדו (כי זה לא מוגדר) אבל פעולות של USSD ככל הנראה כי יעבדו.

מפתחי אפליקציות קצה  יכולים לראות את דרישות ה IMS בRFC ולממש את IR.92 (מה שיאפשר לעבוד גם ב VoLTE וגם ב VoWifi).

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

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

רכיב התקשורת (UE) שלנו יחפש קודם כל רשתות שהוא מכיר (ויודע שניתן להתחבר אליהם אם הם trusted), יבצע זאת ע"י מעבר שמות או יחפש רשתות שמאשרות ביצוע הזדהות סים (EAP-AKA/SIM וכו'). אם זה לא עבר יעבור למוד ה untrstursted בו יחפש את הנקודה אליה צריך להתחבר (לפי רשת הסלולאר שלנו כמו t-mobile.com או לפי הכתובות הרשומות תחת 3gppnetwork).

האימות נכון להיום (שמאפשר את שימוש) כולל דברים מבוססי סים (EAP-AKA) אבל גם דברים שאינם דורשים סים (מה שמאפשר לטאבלט ולדביאן שלנו להתחבר לרשת האלחוט באמצעי EAP-TTLS ו EAP-TLS).

במידה וה AP שלנו דורש הזדהות (hybrid mode או Trusted Mode) את חותמות הלקוח שקיבלנו יש לשמור תחת etc/ssl/certs/  ולהתאים את wpa_supplicant והדפדנים לקרוא משם דוגמאות (כמובן לשנות את הערכים לפי מה שקיבלתם מהספק).


network={
      ssid="TRUSTED-GSM-SSID"
      scan_ssid=1
      key_mgmt=WPA-EAP
      pairwise=CCMP TKIP
      group=CCMP TKIP
      eap=TLS
      identity="$(nonuiccid)@blablagsm.tld"
      ca_cert="/etc/certs/cacert.pem"
      client_cert="/etc/certs/client_blablagsm.pem"
      #or 
      #private_key="client_blablagsm.pem"
      #private_key_passwd="secretuserpassword"
   }
או במקרה של TTLS :
network={
      ssid="UNTRUSTED-GSM-SSID"
      key_mgmt=WPA-EAP
      eap=TTLS
      scan_ssid=1
      pairwise=CCMP TKIP
      group=CCMP TKIP 
      anonymous_identity="anon@blablagsm.tld"
      identity="$(nonuiccid)@blablagsm.tld"
      ca_cert="/etc/certs/ca.pem"
      phase2="autheap=TLS"
      ca_cert2="/etc/certs/cacert.pem"
      client_cert2="/etc/certs/client_blablagsm.pem"
      private_key2="key_client_blablagsm.pem"
      private_key2_passwd="secretuserpassword"
   }


בדביאן על מנת לאפשר את האימות מחדש נצטרך להפעיל ע"י בנייה מחדש עם דגלי ה internetworking מופעלים.

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


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

בצד השרת -

בצד הePDG נוכל להשתמש במחשבי דביאן רגילים, שמריץ שירותים סטאנדרטיים כמו שרת דיאמטר, שירות DNS, שרת ipsec, שרת xcap, שרת איכון גאוגרפי, שירותי SIP ומחבר לשירותי ה IMS של הרשת או משתמש ב OpenIMSCore (או דומה לו) בשביל לספק את היכולות הנדרשות.


הרשתות שבוחרות בשיטת ה untrusted כמובן חשופות להתקופות רגילות (דוגמה T-Mobile) אבל ההוזלה והיכולת להשתמש בצד שלישי בקלות בשביל לספק שירות פותחת אפשרויות שעולות על הסכנה בהתקפות.

יום ראשון, ספטמבר 25, 2016

התקנת חותמת לציתות

כאשר אנו צריכים לאפשר יכולת ציתות במחשב אחד הדברים הפשוטים ביותר הוא התקנת אישור הצפנה בשביל שנוכל לפתוח הצפנות SSL. 

בחלק מהכלים שראיתי יהיו פתיחה ואריזה מחדש של כל מה שעובר תחת 443, פשוט שולחים ללקוח את החותמת שלנו ו"מצפינים" את התעבורה עבורו עם המפתח שלנו.

יש הרבה ספקים שמאפשרים זאת ללא התקנת רכיב נוסף (אני חושב ש fortigate הוא הספק שנתקלתי בו הכי הרבה) אבל יש כאלה שדורשים התקנת חותמת אימות (קובץ crt). הייתרון בהתקנת החותמת שהלקוח לא מקבל הודעות של חיבור לא מאובטח (זה מעצבן).

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

לדעתי האישית עדיף היה אם היו משתמשים ב sslstrip אבל זה עניין של טעם וריח.

את החותמת אפשר להתקין פר תוכנה (דפדפן , לקוח אימייל) או פר מערכת לכל דבר יש את הייתרונות והחסרונות שלו.

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

עבור דביאן :

לדוגמה אם יש לנו צורך להתקין את החותמת של Netspark  נוריד את הקובץ הזה) נקרא לו מקומית כ netpark.crt):

wget http://www.netsparkmobile.com/support/myca.crt -O netspark.crt

אפשר להוריד את אותו הקובץ מספקי השירות שמשתמשים בשרות שלהם (אינטרנט רימון , T4G ,אוניברסיטאות וכו') או מהשרת הראשי של netspark.

עבור fortinet הספק שלכם צריך לתת את הCA שלו (הסבר כאן).
עבור sonicwal אפשר להוריד את החותמת ברירת המחדל.


 את הקובץ נשים ב : 
/usr/share/ca-certificate
ונתקין לכל המערכת ע"י 
sudo dpkg-reconfigure ca-certificates

עכשיו יש לבחור אם אנו סומכים על האישור.

לדעתי האישית התקנה של חותמות כאלה במחשב נייד שיש לו סיכוי להתחבר לרשתות של אחרים זה חתיכת כאב ראש - גם אדם שלישי שהפעיל DPI יוכל לבצע ציתות למחשב אם נכנסים אליו לרשת (כי ה CA הוא אותו ה CA גם אצל לקוח א' וגם לקוח ב' של הספק).

לצערי העוד יותר יותר מדי "vpn"ים אינם מותקנים ע"י חבילות התקנת deb ומכילים טסריטים שידחפו את החותמות שלהם ל /etc/ssl ישירות מה שמקשה לבצע שידרוג או אחזקה של המכונה.