Handling TLS renegotiation updates in stable releases (CVE-2009-3555)

Registered by Marc Deslauriers

The security fixes for CVE-2009-3555 (TLS renegotiation injection) are intrusive and may break application compatibility and interoperability. This session will discuss how to handle these updates for our stable Ubuntu releases.

Blueprint information

Status:
Complete
Approver:
Kees Cook
Priority:
Essential
Drafter:
Marc Deslauriers
Direction:
Needs approval
Assignee:
Marc Deslauriers
Definition:
Approved
Series goal:
Accepted for maverick
Implementation:
Implemented
Milestone target:
milestone icon ubuntu-10.10
Started by
Marc Deslauriers
Completed by
Marc Deslauriers

Related branches

Sprints

Whiteboard

Work items:
merge openssl into maverick: DONE
see if we can default to backwards compatible: DONE
search for and document apps that got patched: DONE
determine what apps need to be patched in stable releases: DONE
come up with test scenario for apps: DONE
push updates into stable releases: DONE

Notes from Gobby:

The security fixes for CVE-2009-3555 (TLS renegotiation injection) are
intrusive and may break application compatibility and interoperability.
This session will discuss how to handle these updates for our stable Ubuntu releases.

http://people.canonical.com/~ubuntu-security/cve/2009/CVE-2009-3555.html

* Services
  * Jabber (psi)
  * postgresql
    - already pushed to -security
      "ssl_renegotiation_limit" not sure what the default is
  * Jetty
  * alpine
  * openvpn
  * IMAP/POP3 ? fetchmail broke temporarily, was openssl "l" bad? "m" is ok?

* New server cannot talk to old client

* What do we do for older releases?

  * each server that uses TLS needs to handle this

  * identify server software that needs to be modified based on protocols that
    support/depend on renegotiation
    ACTION: identify protocols
    ACTION: identify affected servers
    ACTION: identify failure scenarios
  * go through Fedora bugs
  * possibly just upload to maverick
    - be careful because we will have new servers as well
    ACTION: go through changelogs for identified servers for fixes
  * identify openssl options that can be used in servers (ie, can we be strict
    if openssl is compiled for compatibility)
  * if possible offer servers that are compatible or offer a config option to turn on
    strict mode, but have servers be in compatibility mode. Verify we can do the
    following:
    - old client to new server is ok (server uses compatibility)
    - new client to new server (both use new protocol)
    - new client to old server is ok (client uses compatibility)
  * as a transitional step, have servers in compatibility mode, so the old clients
    don't break, but new clients can use the new protocol. When servers are patched
    can turn on strict mode everywhere. Marc states that servers don't operate
    like this. Needs more investigation

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.