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
