[SR-Users] Kamailio -topoh- and Via headers

Gonzalo Gasca gascagonzalo at gmail.com
Tue Oct 7 10:57:03 CEST 2014


Hi Daniel,

I see the "Via" header in both initial Websocket upgrade response
(101) and in SIP 200 OK from Kamailio when Sipml5 client is
registering.

At SIP level including rport in initial REGISTER message from client
and getting a "received" field from Kamailio makes sense and I will
use your recommended solution.

When I look at this Section:
https://tools.ietf.org/html/rfc7118#section-5.3

I have WSS at client level hence I expect users not to see WS messages
including the "received" field but...
I'm wondering if in the case of WS(Not secure), Kamailio replying to
the 101 WS using Via header may reveal inside information and if it is
possible to change this?

Protocols\r\n]
             [Message: HTTP/1.1 101 Switching Protocols\r\n]
             [Severity level: Chat]
             [Group: Sequence]
          Request Version: HTTP/1.1
          Status Code: 101
          Response Phrase: Switching Protocols
    --> Via: SIP/2.0/TCP 172.31.22.2:37137\r\n


Thanks Daniel

-Gonzalo

On Tue, Oct 7, 2014 at 12:01 AM, Daniel-Constantin Mierla
<miconda at gmail.com> wrote:
> Do you refer to the http response only? Or to SIP as well?
>
> Daniel
>
>
> On 07/10/14 06:19, Gonzalo Gasca wrote:
>>
>> Daniel,
>> I will re-write it in Kamailio, seems to be that during initial WS
>> negotiation (HTTP Connection Upgrade), Kamailio is already including
>> the Via header:
>>
>>      Via: SIP/2.0/TCP 172.31.22.2:37137\r\n
>>
>> Which as you said is perfectly fine, Im just trying to hide my info.
>>
>> Thanks
>> -Gonzalo
>>
>> No.     Time         Source                Destination
>> Protocol Length Info
>>       13 21:00:41.016 172.31.22.2           172.31.27.85          HTTP
>>     814    GET / HTTP/1.1
>>
>> Frame 13: 814 bytes on wire (6512 bits), 814 bytes captured (6512 bits)
>> Ethernet II, Src: 06:17:4e:87:69:98 (06:17:4e:87:69:98), Dst:
>> 06:79:4f:ef:e3:d6 (06:79:4f:ef:e3:d6)
>> Internet Protocol Version 4, Src: 172.31.22.2 (172.31.22.2), Dst:
>> 172.31.27.85 (172.31.27.85)
>> Transmission Control Protocol, Src Port: 37137 (37137), Dst Port:
>> na-localise (5062), Seq: 1, Ack: 1, Len: 748
>> Hypertext Transfer Protocol
>>      GET / HTTP/1.1\r\n
>>          [Expert Info (Chat/Sequence): GET / HTTP/1.1\r\n]
>>          Request Method: GET
>>          Request URI: /
>>          Request Version: HTTP/1.1
>>      Host: ramenlabs.io:5062\r\n
>>      Upgrade: websocket\r\n
>>      Connection: Upgrade\r\n
>>      Pragma: no-cache\r\n
>>      Cache-Control: no-cache\r\n
>>      Origin: https://www.ramenlabs.io\r\n
>>      Sec-WebSocket-Version: 13\r\n
>>      User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4)
>> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2180.0
>> Safari/537.36\r\n
>>      Accept-Encoding: gzip, deflate, sdch\r\n
>>      Accept-Language: en-US,en;q=0.8\r\n
>>      Cookie: __utmt=1;
>> __utma=257296520.931028039.1410155955.1412651114.1412653901.42;
>> __utmb=257296520.1.10.1412653901; __utmc=257296520;
>>
>> __utmz=257296520.1410155955.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)\r\n
>>      Sec-WebSocket-Key: QR+qynpQ7+7psMScB/WkQQ==\r\n
>>      Sec-WebSocket-Extensions: permessage-deflate;
>> client_max_window_bits\r\n
>>      Sec-WebSocket-Protocol: sip\r\n
>>      \r\n
>>      [Full request URI: http://ramenlabs.io:5062/]
>>
>>
>> No.     Time         Source                Destination
>> Protocol Length Info
>>       15 21:00:41.017 172.31.27.85          172.31.22.2           HTTP
>>     314    HTTP/1.1 101 Switching Protocols
>>
>> Frame 15: 314 bytes on wire (2512 bits), 314 bytes captured (2512 bits)
>> Ethernet II, Src: 06:79:4f:ef:e3:d6 (06:79:4f:ef:e3:d6), Dst:
>> 06:17:4e:87:69:98 (06:17:4e:87:69:98)
>> Internet Protocol Version 4, Src: 172.31.27.85 (172.31.27.85), Dst:
>> 172.31.22.2 (172.31.22.2)
>> Transmission Control Protocol, Src Port: na-localise (5062), Dst Port:
>> 37137 (37137), Seq: 1, Ack: 749, Len: 248
>> Hypertext Transfer Protocol
>>      HTTP/1.1 101 Switching Protocols\r\n
>>          [Expert Info (Chat/Sequence): HTTP/1.1 101 Switching
>> Protocols\r\n]
>>              [Message: HTTP/1.1 101 Switching Protocols\r\n]
>>              [Severity level: Chat]
>>              [Group: Sequence]
>>          Request Version: HTTP/1.1
>>          Status Code: 101
>>          Response Phrase: Switching Protocols
>>      Via: SIP/2.0/TCP 172.31.22.2:37137\r\n
>>      Sec-WebSocket-Protocol: sip\r\n
>>      Upgrade: websocket\r\n
>>      Connection: upgrade\r\n
>>      Sec-WebSocket-Accept: rb6Ng4aiTHNyZatk74btU9vZNPk=\r\n
>>      Server: Llamato SipRegistrar(1.0)\r\n
>>      Content-Length: 0\r\n
>>      \r\n
>>
>> On Mon, Oct 6, 2014 at 1:06 AM, Daniel-Constantin Mierla
>> <miconda at gmail.com> wrote:
>>>
>>> Hello,
>>>
>>> received is added because the client requests that via rport parameter or
>>> because of using rport. If the processed request is REGISTER, you can try
>>> removing rport/received parameters from Via, then do msg_apply_changes().
>>>
>>> However, without rport enforcement, the response might not be routed
>>> back,
>>> because SIP says to send it back to the address in Via, which is invalid
>>> in
>>> websocket case.
>>>
>>> Maybe you can rewrite headers in nginx or use kamailio as a proxy/load
>>> balancer instead of nginx and then you have plenty of options to play
>>> with
>>> sip headers.
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>> On 06/10/14 02:39, Gonzalo Gasca wrote:
>>>
>>> I'm using Kamailio as SIP Registrar using Websockets.
>>> My topology looks like this:
>>>
>>> Sip client (sipml5) ---> wss ---> Nginx ---> ws ---> Kamailio 4.1.5
>>>
>>> When I look into my SipMl5 application in the Register Message 200 OK
>>> from Kamailio I see the Nginx private IP address 172.31.22.2
>>>
>>> Via: SIP/2.0/WSS
>>>
>>> df7jal23ls0d.invalid;rport=37111;received=172.31.22.2;branch=z9hG4bKtv75otkzmPVsdNWevweLt4TN9JnLnQ0p
>>>
>>> How can I remove private IP Address in Via header to achieve topology
>>> hiding?
>>>
>>>  From Kamailio logs:
>>>
>>> Oct  6 00:34:21 ip-172-31-27-85 /usr/sbin/kamailio[8941]: DEBUG:
>>> registrar [reply.c:374]: build_contact(): created Contact HF: Contact:
>>>
>>> <sips:gogasca at df7jal23ls0d.invalid;rtcweb-breaker=no;transport=wss>;expires=200#015#012
>>> Oct  6 00:34:21 ip-172-31-27-85 /usr/sbin/kamailio[8941]: DEBUG: sl
>>> [sl.c:288]: send_reply(): reply in stateless mode (sl)
>>> Oct  6 00:34:21 ip-172-31-27-85 /usr/sbin/kamailio[8941]: DEBUG:
>>> <core> [msg_translator.c:204]: check_via_address():
>>> check_via_address(172.31.22.2, df7jal23ls0d.invalid, 0)
>>> O
>>>
>>>
>>> Version: kamailio 4.1.5 (x86_64/linux)
>>>
>>> # ------ topoh --------
>>>
>>> modparam("topoh", "mask_key", "opencall")
>>> modparam("topoh", "mask_ip", "<Public IP Address of Kamailio>")
>>> modparam("topoh", "vparam_prefix", "llamato")
>>> modparam("topoh", "mask_callid", 1)
>>> modparam("topoh", "sanity_checks", 1)
>>>
>>>
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users at lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>> --
>>> Daniel-Constantin Mierla
>>> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>>
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users at lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>
>
> --
> Daniel-Constantin Mierla
> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>



More information about the sr-users mailing list