News for hackers. Stuff that matters.
Re:I exploited TLS-SNI-01 issuing Let's Encrypt SSL-certs fo... by mentat on Tuesday January 29, 2019 @03:32PM (#19029558)
If port 80 is open and there's been a mistake with cookie marking, then you can passively leak your critical cookies over an insecure connection. Having "seen this in real life", it's better to just not accept 80 to protect against developers making that mistake (along with other mitigation strategies).
Re:I exploited TLS-SNI-01 issuing Let's Encrypt SSL-certs fo... by WatchDog on Tuesday January 29, 2019 @06:06PM (#19030775)
If you have misconfigured cookies, having your server accept port 80 or not wont matter to a non-passive man-in-the-middle. They will just accept port 80 traffic and read the cookies.
Re:I exploited TLS-SNI-01 issuing Let's Encrypt SSL-certs fo... by schoen on Tuesday January 29, 2019 @06:28PM (#19030980)
It's clear that there's a difference between an active and a passive attacker here. Closing port 80 protects against the passive attacker, but not against the active attacker (with regard to SSL stripping, insecure submission of old forms, and cookies not flagged as secure). Both kinds of attackers are real.
Re:I exploited TLS-SNI-01 issuing Let's Encrypt SSL-certs fo... by qu4z-2 on Tuesday January 29, 2019 @08:27PM (#19031725)
I'm fairly sure you can also just get the client to request http://example.com:443/. The cookies get sent before the server goes "Wait, what?".
Re:I exploited TLS-SNI-01 issuing Let's Encrypt SSL-certs fo... by schoen on Tuesday January 29, 2019 @10:11PM (#19032303)
This thread seems to agree with you:

https://stackoverflow.com/questions/1612177/are-http-cookies...

I just tested this and I was able to confirm your suggestion with Firefox, watching with a packet sniffer while connecting to my own site with http://example.com:443/ after previously setting a cookie over https://example.com/. The cookie was clearly visible in the packet log.