Right now, tbpl sort of guesses that it's really talking to elasticsearch1.metrics.sjc1.mozilla.com:9200 because probably it would be hard for someone to get themselves inserted into the network between phx and sjc1 to intercept traffic, probably. It would be better if it knew that it was really talking to it, because it got a valid cert when it connected to https://elasticsearch1.metrics.sjc1.mozilla.com. Probably, it doesn't matter and nobody would ever need to MITM orangefactor for an attack, probably. Needing to fake up the results of test failures after you snuck in an exploit isn't very likely, probably. It's at least as unlikely as someone getting a trusted CA to issue them a cert for Google and Windows Update, and how likely is that?
ES doesn't have any sort of handshake protocol to authenticate its identity to a requester/requestee. The TBPL instance relies on external firewall rules and assumes that all traffic coming to it is valid. I am not a security expert to comment on MITM; but ES doesn't have any security features planned for next 6 months.
resolving wontfix based on age. If there's a plan, feel free to reopen.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
Product: Webtools → Tree Management
Product: Tree Management → Tree Management Graveyard
You need to log in before you can comment on or make changes to this bug.