Hi all, While looking into XX-5417 I did some prototyping and thinking about how to get where we eventually want to be. That is to have phones load their configuration over HTTPS, and with authentication. A rough draft proposal is below.
It's already been agreed that the standard HTTP/HTTPS ports (80 & 443) will be hijacked for delivery of device profiles. Though, builds for special environments could overwrite this. http://list.sipfoundry.org/archive/sipx-dev/msg17575.html Using the default ports will help keep the provisioning URLs tidy and easy to remember. It would be highly desirable if the web server that performs profile delivery were dedicated to that specific task. I think the last Operational dependency on apache will be removed with delivery of the new VM (XX-4753.) At that point, the web sever will be used exclusively for profile delivery. (Although as a courtesy, its index.html would provide browser forwarding to sipXconfig's HTTPS port 8443.) The goal is to keep private the user information (especially SIP passwords) in the device profiles. This will be achieved by transporting the device configuration files only over HTTPS, and authenticating all access against Username/PIN credentials. To this end, I don't see any reason to make device configuration files available over HTTP. For one or two following releases we should maintain the option for TFTP and FTP access, with a GUI screen to turn on/off. That should give ample time for superadmin's in existing deployments to update the phone configurations. The default for fresh installs would need to be off, but ideally upgraded systems would be on by default. Also towards making the provisioning URLs tidy and easy to remember, the device configuration files would be placed directly in the document root of the HTTPS server. I also don't see any need to keep the current HTTP port 8090 and HTTPS port 8091 configuration around. One of the major inconveniences of HTTPS will be encountered on systems using a self-signed certificate. The phone must have previously loaded the Trusted CA certificate. I've seen this done four different ways: - Contents pasted into an edit box in the phone Web GUI (LG-Nortel 68xx) - Load from a specified HTTP URL (Polycom and ipDialog SipTone V) - Load from a .crt file via the phone Web GUI (SNOM and ipDialog SipTone V) - Accessed from the Windows/MacOS certificate store (CounterPath), previously loaded by double-clicking on a .crt file All of these methods should be supported. Access to the current Trusted CA certificate should be facilitated with a new "Current" screen under "Web Certificates". On this new screen, there would be: - an HTTP link to download the ca.<FQDN>.crt file (GUI login not required) - a simplified HTTP link to download the ca.<FQDN>.crt file: http://<IP>/1, which is easy to compose in a Polycom phone menu - the certificate contents available for text copy from an edit box (similar to Certificate Signing Request on the "Generate" screen) This page should also display the MD5 fingerprint of the certificate. Polycoms show you the MD5 fingerprint of the certificate before storing it, which can be used to prevent man-in-the-middle attacks. (The "View" button in Firefox also allows you to see the MD5 fingerprint before confirming the security exception.) We'll need the web server to authenticate the User/PIN credentials used by the phone. I used lighttpd to prototype this, and confirmed that an htpasswd file with the user:realm:pintoken fields from the users DB table (or credentials.xml) works just fine. It's also possible to re-write this file and have those changes used without a lighttpd restart, though I'm not sure that's supported. Anyway, we'll probably want to re-generate an htpasswd file whenever user/credentials changes occur. I think sipXsupervisor is best positioned to do this, though I'm not sure if its prepared to handle files not in XML format. Thoughts? -Paul [email protected] _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
