> On 18 Nov 2017, at 20:05, Alex Balashov <[email protected]> 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 <http://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 rely more on developers than the documentation from IETF. I would like this to change so that the IETF has proper documentation of a secure way to run SIP. /O _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
