Re: [Sip-implementors] Some TLS questions

2017-11-21 Thread Alex Balashov 
On Wed, Nov 22, 2017 at 01:00:47AM -0500, Alex Balashov wrote:

> You say Kamailio supports SNI? How?

I suppose the answer lies in multiple TLS configs for each domain:

https://kamailio.org/docs/modules/5.0.x/modules/tls.html#tls.p.config

-- Alex

-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) 
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Some TLS questions

2017-11-21 Thread Alex Balashov 
On Tue, Nov 21, 2017 at 12:13:14PM +0100, Olle E. Johansson wrote:

> Propably because they don’t trust your CA. You need to install the
> CA cert in the trust store on the systems you run Bria and Blink on
> (and remember to remove it later)

Since I wrote that, I got an authoritative certificate for the host from
Comodo. Its CN happens to correspond to the serving SIP domain &
canonical hostname, so I cannot tell whether the UAs properly deal with
SAN.

Bria and my Polycom VVX 411 validate the certificate. Bria does not,
despite using OpenSSL defaults which include root CA certs/chains for
several Comodo issuers. I suspect that this is an adequate bellwether of
how other UAs will behave: inconsistently.

I have heard it said by some that authoritative certificates from
well-known CAs are not a big thing in the SIP TLS world. The folklore
has it that most large service providers and enterprises run their own
CAs and simply mass-provision their own certificates into devices.

I cannot say if it's true. But if it is true, it would greatly differ
from the practice in the WWW world, it would seem.

I am also unsure as to the status of LetsEncrypt. It seems a handful of
handset vendors might have been persuaded to support it. 

> SAN is an extension so that ONE certificate is valid for multiple names.
> If you have SAN fields, the CN of the cert is ignored.
> 
> SNI is a TLS function where the client says “I’m going to connect to
> alex.domain.com ” early in the TLS negotiation so 
> that the server
> can select a valid certificate. The server now has one certificate
> per domain and selects which one to use for the session.
> 
> In summary
>  * SAN = One cert, many names, one server
>  * SNI = One cert per domain, one server

Interesting. For my use-case, SNI might be more appropriate than SAN; 

You say Kamailio supports SNI? How?

> > Interesting; so as a practical matter, it is formally acceptable to send
> > a request with neither sips: scheme nor ;transport=TLS, just happen to
> > send it via TLS? The only indication of transport would then be
> > SIP/2.0/TLS in the Via header, no?

> Right. And hopefully the server will add proper headers (what they are
> without the transport flag) to the record-route and route headers.
> THis is a bug in SIP.

Kamailio adds RRs with ;transport=tls for the appropriate hop.  

> You need to look at SIP outbound so that the client opens the
> connection to the server and the server has the right to use
> the *very same* connection for messages to the client. Without
> outbound, the server is required to open a TLS connection to the
> client and vertify the client’s certificate against the target URI.

I assume it is common practice to turn off verification of the client
certificate? That is what I have done in my Kamailio test environment.

> In summary, one can get SIP over TLS to work if you break some parts
> of the RFCs and rely more on developers than the documentation from
> IETF. 

That has been consistent with my exploration thus far.

-- Alex

-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) 
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Some TLS questions

2017-11-21 Thread Roman Shpount 
On Tue, Nov 21, 2017 at 6:13 AM, Olle E. Johansson  wrote:

>
> >>
> >> Not really. I haven’t seen any server that enforces this policy. At
> >> the time of the writing of this RFC wildcards where highly suspected
> >> for abuse but I haven’t seen much discussions about this lately.
> >> Propably because of SNI and SNA (see below).
> >
> > I am more concerned about clients (e.g. phones, softphones) not
> > accepting this.
> Ok, not seen that either.
>
>
Skype For Business would be one example where SIPS client does not accept
wildcard certificates. I definitely seen other clients that failed to
validate wildcard certificates.

Regards,
_
Roman Shpount
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Some TLS questions

2017-11-21 Thread Olle E. Johansson 

> On 18 Nov 2017, at 20:05, Alex Balashov  wrote:
> 
> Hello Olle,
> 
> Thank you for the education! 
> 
> By way of further question to the list:
> 
> On Sat, Nov 18, 2017 at 12:21:09PM +0100, Olle E. Johansson wrote:
> 
>> They are important and indicate that further work is needed here.
>> Please also engage the SIPCORE wg in IETF with questions like these.
> 
> I am not sure that my ignorance of SIP-TLS basics constitutes a
> deficiency in the work of the relevant IETF WG. 
Well, SIPCORE needs to know that there are issues unresolved…

> 
>>> 1. Are wildcard certificates (commonName of *.domain.com) permitted for
>>> SIP-TLS?
>>> 
>>> RFC 5922 § 7.2 seems to suggest they are not:
>>> [...]
>>> Is this true in the wild?
> 
>> Not really. I haven’t seen any server that enforces this policy. At
>> the time of the writing of this RFC wildcards where highly suspected
>> for abuse but I haven’t seen much discussions about this lately.
>> Propably because of SNI and SNA (see below).
> 
> I am more concerned about clients (e.g. phones, softphones) not
> accepting this.
Ok, not seen that either.

> 
>> Server Name Indication is supported in Kamailio and is the way forward
>> to solve this problem. But if, as you say, the server only supports
>> one certificate then Subject Alt names is the way to go. Look at the
>> cert for Google services for an example. This means that you will have
>> to change certificate for every new customer, which is a bad thing.
> 
> This may be getting a bit applied and away from the focus of this list,
> but:
> 
> I successfully built (after painstaking research) a self-signed
> certificate with openssl last night with a CN of domain.com and SANs of
> sip.domain.com and sipgw.domain.com last night. It was signed by a
> self-signed (non-authoritative) CA I also made using the usual openssl
> folk traditions for that.
> 
> Both Bria and Blink refused to validate the certificate, but I cannot
> figure out if this is because the CA is non-authoritative or because
> they don't recognise the SNA attributes. 
Propably because they don’t trust your CA. You need to install the
CA cert in the trust store on the systems you run Bria and Blink on
(and remember to remove it later)

> 
> What is the difference between SAN and SNI?
SAN is an extension so that ONE certificate is valid for multiple names.
If you have SAN fields, the CN of the cert is ignored.

SNI is a TLS function where the client says “I’m going to connect to
alex.domain.com ” early in the TLS negotiation so that 
the server
can select a valid certificate. The server now has one certificate
per domain and selects which one to use for the session.

In summary
 * SAN = One cert, many names, one server
 * SNI = One cert per domain, one server

> 
>> Neither. It’s deprecated in RFC 3261 and something I’ve tried to get
>> interest in reinstating. We need a way to indicate TLS transport.
> 
> Interesting; so as a practical matter, it is formally acceptable to send
> a request with neither sips: scheme nor ;transport=TLS, just happen to
> send it via TLS? The only indication of transport would then be
> SIP/2.0/TLS in the Via header, no?
Right. And hopefully the server will add proper headers (what they
are without the transport flag) to the record-route and route headers.
THis is a bug in SIP.

> 
> Why does this seem to differ for SIP over standard TCP? As far as I can
> see, almost all TCP-speaking UAs send ;transport=tcp. Perhaps I'm wrong.
> I guess RFC 3261 § 26.2.2 speaks to that.

Yes, I don’t know the reason why TLS was deemed not a transport.
Regardless of the RFC, everyone treats it as one and so does our beloved
Kamailio.

> 
>> No, any URI scheme can be carried over TLS. Many implementations look
>> for the TLS Naptr/SRV first and if existing always use TLS.  SIPS is
>> required to use over a protected transport. But it’s impossible to
>> implement, so forget about the SIPS: uri.
> 
> Thanks, that's an important point of clarity.
> 
> In my particular case, I am tinkering with an implementation that
> provides TLS + SRTP on the "last mile" but forwards the traffic
> unprotected to the SIP termination supply chain, which almost
> universally does not generally provide transport or media security, at
> least not in the USA. Nevertheless, last-mile encryption is required to
> meet some compliance and regulatory requirements. It's absurd.

You need to look at SIP outbound so that the client opens the
connection to the server and the server has the right to use
the *very same* connection for messages to the client. Without
outbound, the server is required to open a TLS connection to the
client and vertify the client’s certificate against the target URI.
Which is not the way it works out there with NATs in the way.
For this, I’ve tried to propose a “simple outbound”, but had to
push it back to the  “future work” folder.

In summary, one can get SIP over TLS to work if you break some
parts of the RFCs and r

Re: [Sip-implementors] Some TLS questions

2017-11-18 Thread Alex Balashov 
Hello Olle,

Thank you for the education! 

By way of further question to the list:

On Sat, Nov 18, 2017 at 12:21:09PM +0100, Olle E. Johansson wrote:

> They are important and indicate that further work is needed here.
> Please also engage the SIPCORE wg in IETF with questions like these.

I am not sure that my ignorance of SIP-TLS basics constitutes a
deficiency in the work of the relevant IETF WG. 

> > 1. Are wildcard certificates (commonName of *.domain.com) permitted for
> > SIP-TLS?
> > 
> > RFC 5922 § 7.2 seems to suggest they are not:
> > [...]
> > Is this true in the wild?

> Not really. I haven’t seen any server that enforces this policy. At
> the time of the writing of this RFC wildcards where highly suspected
> for abuse but I haven’t seen much discussions about this lately.
> Propably because of SNI and SNA (see below).

I am more concerned about clients (e.g. phones, softphones) not
accepting this.

> Server Name Indication is supported in Kamailio and is the way forward
> to solve this problem. But if, as you say, the server only supports
> one certificate then Subject Alt names is the way to go. Look at the
> cert for Google services for an example. This means that you will have
> to change certificate for every new customer, which is a bad thing.

This may be getting a bit applied and away from the focus of this list,
but:

I successfully built (after painstaking research) a self-signed
certificate with openssl last night with a CN of domain.com and SANs of
sip.domain.com and sipgw.domain.com last night. It was signed by a
self-signed (non-authoritative) CA I also made using the usual openssl
folk traditions for that.

Both Bria and Blink refused to validate the certificate, but I cannot
figure out if this is because the CA is non-authoritative or because
they don't recognise the SNA attributes. 

What is the difference between SAN and SNI?

> Neither. It’s deprecated in RFC 3261 and something I’ve tried to get
> interest in reinstating. We need a way to indicate TLS transport.

Interesting; so as a practical matter, it is formally acceptable to send
a request with neither sips: scheme nor ;transport=TLS, just happen to
send it via TLS? The only indication of transport would then be
SIP/2.0/TLS in the Via header, no?

Why does this seem to differ for SIP over standard TCP? As far as I can
see, almost all TCP-speaking UAs send ;transport=tcp. Perhaps I'm wrong.
I guess RFC 3261 § 26.2.2 speaks to that.

> No, any URI scheme can be carried over TLS. Many implementations look
> for the TLS Naptr/SRV first and if existing always use TLS.  SIPS is
> required to use over a protected transport. But it’s impossible to
> implement, so forget about the SIPS: uri.

Thanks, that's an important point of clarity.

In my particular case, I am tinkering with an implementation that
provides TLS + SRTP on the "last mile" but forwards the traffic
unprotected to the SIP termination supply chain, which almost
universally does not generally provide transport or media security, at
least not in the USA. Nevertheless, last-mile encryption is required to
meet some compliance and regulatory requirements. It's absurd.

-- Alex

-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) 
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Some TLS questions

2017-11-18 Thread Olle E. Johansson 

> On 17 Nov 2017, at 21:21, Alex Balashov  wrote:
> 
> Hi,
> 
> A few questions about TLS. I apologise that they're kind of idiotic,
They are important and indicate that further work is needed here.
Please also engage the SIPCORE wg in IETF with questions like these.

> I'm
> new to SIP over TLS. I have been a big supporter of LetsDecrypt, a
> certificate authority sponsored by the NSA. :-)
;-)

> 
> 1. Are wildcard certificates (commonName of *.domain.com) permitted for
> SIP-TLS?
> 
> RFC 5922 § 7.2 seems to suggest they are not:
> 
>   Implementations MUST NOT match any form of wildcard, such as a
>   leading "." or "*." with any other DNS label or sequence of
>   labels.  For example, "*.example.com" matches only
>   "*.example.com" but not "foo.example.com".  Similarly,
>   ".example.com" matches only ".example.com", and does not match
>   "foo.example.com".
> 
>  RFC 2818 [7] (HTTP over TLS) allows the dNSName component to
>  contain a wildcard; e.g., "DNS:*.example.com".  RFC 5280
>  [6], while not disallowing this explicitly, leaves the
>  interpretation of wildcards to the individual specification.
>  RFC 3261 [2] does not provide any guidelines on the presence
>  of wildcards in certificates.  Through the rule above, this
>  document prohibits such wildcards in certificates for SIP
>  domains.
> 
> Is this true in the wild?
Not really. I haven’t seen any server that enforces this policy. At the time
of the writing of this RFC wildcards where highly suspected for abuse but
I haven’t seen much discussions about this lately. Propably because of
SNI and SNA (see below).

> If so, how to deal with a SIP server that
> serves multiple domains but supports only one certificate and key pair?
Server Name Indication is supported in Kamailio and is the way forward
to solve this problem. But if, as you say, the server only supports one
certificate then Subject Alt names is the way to go. Look at the cert
for Google services for an example. This means that you will have
to change certificate for every new customer, which is a bad thing.

> 
> 2. Is ';transport=tls' or ';transport=TLS' appropriate? I've seen both,
> but which one is correct?
Neither. It’s deprecated in RFC 3261 and something I’ve tried to get
interest in reinstating. We need a way to indicate TLS transport.

> 
> 3. Does a 'sips:' URI scheme imply ';transport=tls', or must the latter
> be explictly included? In other words, will a 'sips:' URI like
> 'sips:5551...@domain.com' be constructed to be
> 'sips:5551...@domain.com;transport=tls’?
SIPS: should die. Really. There are RFCs that try to clear up the mess
in RFC 3261, but it really doesn’t deliver what it seems to promise.
We do need to work on this. Again, I tried to start a discussion.

https://www.slideshare.net/oej/sips-must-die-die-die-about-tls-usage-in-the-sip-protocol
> 
> 4. Is a 'sips:' URI scheme mandatory for secure transport? What are the
> implications of a 'sip:' URI with ';transport=tls' affixed?
No, any URI scheme can be carried over TLS. Many implementations
look for the TLS Naptr/SRV first and if existing always use TLS.
SIPS is required to use over a protected transport. But it’s impossible
to implement, so forget about the SIPS: uri.

The SIP: uri may, depending on DNS for the service, be forced to use
TLS. 

> 
> 5. Is it permitted for a proxy to bend a 'sips:' Request URI scheme to
> 'sip:' when adapting TLS to an insecure transport?
No, that’s especially mentioned as a no-no in the RFC:
If I remember correct, a proxy may upgrade but not downgrade.

Cheers,
/O
> 
> Many thanks!
> 
> -- Alex
> 
> -- 
> Alex Balashov | Principal | Evariste Systems LLC
> 
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) 
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Some TLS questions

2017-11-17 Thread Roman Shpount 
HI,

My answers are inline:

On Fri, Nov 17, 2017 at 3:21 PM, Alex Balashov 
wrote:

> A few questions about TLS. I apologise that they're kind of idiotic, I'm
> new to SIP over TLS. I have been a big supporter of LetsDecrypt, a
> certificate authority sponsored by the NSA. :-)
>
> 1. Are wildcard certificates (commonName of *.domain.com) permitted for
> SIP-TLS?
>
> Is this true in the wild? If so, how to deal with a SIP server that
> serves multiple domains but supports only one certificate and key pair?
>

This is true for at least some implementations. Your commonName must match
the DNS name exactly. Keep in mind that if SRV records are used, commonName
must match DNS name in the SRV record, not the host name in SIP URL.


> 2. Is ';transport=tls' or ';transport=TLS' appropriate? I've seen both,
> but which one is correct?
>

Neither. sips URL implies TLS transport. SIP can be used with transport=udp
or transport=tcp, but not with transport=tls, which is not defined. There
are multiple implementations that use sip URLs with transport=tls, but
these are not standard. Also, transport URL parameter is not case
sensitive, so ';transport=tls' and ';transport=TLS'  should mean the same
thing.


> 3. Does a 'sips:' URI scheme imply ';transport=tls', or must the latter
> be explictly included? In other words, will a 'sips:' URI like
> 'sips:5551...@domain.com' be constructed to be
> 'sips:5551...@domain.com;transport=tls'?
>

See above. There is no 'transport=tls' defined. sips requires end-to-end
use of TLS and does not allow any other transports.


> 4. Is a 'sips:' URI scheme mandatory for secure transport? What are the
> implications of a 'sip:' URI with ';transport=tls' affixed?
>

sips means end-to-end secure transport. It means that all Route URLs should
be sips as well. Transport tls with sip URL is used to indicate that only
specific hop is secure and other Route URLs can use other transports. This
is how, for instance, OpenSIPS is using it.

5. Is it permitted for a proxy to bend a 'sips:' Request URI scheme to
> 'sip:' when adapting TLS to an insecure transport?
>

No, according to the specifications, it is not allowed for the proxy to
change sips to sip.  There are numerous implementations which still do it.

Regards,
_
Roman Shpount
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors