[wp-trac] [WordPress Trac] #43320: Harden API requests against man-in-the-middle attacks

[WordPress Trac]

#43320: Harden API requests against man-in-the-middle attacks
-------------------------+------------------------------
 Reporter:  iandunn      |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  low          |   Milestone:  Awaiting Review
Component:  Security     |     Version:  3.7.1
 Severity:  minor        |  Resolution:
 Keywords:               |     Focuses:
-------------------------+------------------------------

Comment (by dakami):

 (A bug finder asked me to comment.)

 Insecure updates are a fairly settled matter at this point.  The network
 is not allowed to achieve arbitrary code execution.  I'm not aware of any
 mildly popular operating system or programming language that neither signs
 its packages nor operates over HTTPS, sometimes both.

 Wordpress is more popular than most OS's and languages.  (Congratulations,
 I use it myself.)

 Package signing is a fairly significant undertaking, and it's my
 understanding there is also content from http://api.wordpress.com that
 gets rendered in an administrative context thus allowing takeover.  This
 is the common class of bugs you see here -- nailing down _everything_ that
 needs to get signed and authenticated is difficult.

 "Just use HTTPS" is a completely reasonable path.  Perfect, good, etc.

 The goalposts here have indeed moved; in 2018, sites not using HTTPS are
 being outright declared insecure by Chrome.  Google's not wrong.

 I'm sympathetic to the concern that there are servers with broken TLS
 stacks.  At this point, the universality of secure updates should reduce
 that risk to tolerable levels.  But you should be able to measure it at
 the https://api.wordpress.com endpoint -- look for TLS sessions that do
 not transition into exchanging data.  I can provide Wireshark scripts to
 do this if it would be helpful.  It is also feasible to press into service
 other stacks that should be ambiently available if PHP/libcurl is
 malfunctioning.  Python comes to mind as a common coinstall due to its
 status as OS dependency, and at the extreme there are pure Python TLS
 stacks you could stub in.

 Realistically though, I think you'll find from https://api.wordpress.com
 data that the breakage rate is pretty low, just because the same
 dependencies you have for TLS are shared by other codebases that must
 work.  And if things are that broken, it probably is the sort of thing you
 should ask an administrator to fix.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/43320#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform