The Drupal Security Team approved this issue for public release.
Original Report by @fgm
There is an issue with the core-generated Date HTTP header on cached responses. I'm reporting it first instead of the public tracker because I have a feeling it might cause a security issue, although I'm not sure how: I can see situations where this Date header might be used to validate sensitive data, for instance, and it would open a non-integrity window.
You can see this issue by:
1. Installing a fresh D8.5.1
2. Disable Internal Page Cache (IPC) and Dynamic Page Cache (DPC)
3. Fetch the site using e.g. curl -I http://site.localhost (fetch)
4. Date header, will match current time, t0
5. Enable IPC
6. Fetch
7. Date header will match current time, now t1, and have X-Drupal-Cache MISS
8 Fetch
8. Date header will match t1 (should be > t1), and have X-Drupal-Cache HIT
9. Drush CR
10 Fetch
11. Date header will match current time, now t2, and have X-Drupal-Cache MISS
12. Disable IPC, Enable DPC
13. Fetch
14. Date header will match current time, now t3, and have X-Drupal-Dynamic-Cache MISS
15. Fetch
16. Date header will match t3 (should be > t3), and have X-Drupal-Dynamic-Cache HIT
17. Drush CR
18 Fetch
19. Date header will match current time, now t4, and have X-Drupal-Cache MISS
So, in short, any time a response is served from either DPC or IPC, it bears the timestamp it was generated instead of the current timestamp. Flushing the cache resets it in both cases.