<span style="font-family: Arial; font-size: 13px;"><i>See embedded answers please...</i><br><br>On 7/11/2014 at 2:38 PM, "Jeremy Chadwick" <jdc@koitsu.org> wrote:<blockquote style="border-left:solid 1px #ccc;margin-left:10px;padding-left:10px;">Few things (first two points might seem like I'm nitpicking but I just<br>want clarification):<br><br>1. What is an "HTTP RST"?  RST implies TCP RST, which is independent of<br>a layer 7 protocol like HTTP.  So are you saying you're seeing TCP RSTs<br>or are you saying you see something indecipherable (due to SSL use)<br>that causes the TCP connection to cleanly shut down?<br><br><i>Meh, yeah, I was being sloppy, posting what Wireshark said vs. the correct technical detail. It was receiving TCP RST on the HTTPS data connection within the TLS tunnel.</i><br><br>2. I assume these are "standard HTTPS" connections (TCP port 443)?  I<br>ask because someone mentioning TLS when also mentioning HTTP (and not<br>use of the term HTTPS) makes me think of RFC 2817 (which allows a<br>plaintext HTTP 1.1 connection to be upgraded to TLS 1.1 still across<br>TCP port 80).<br><br><i>HTTPS connection to 443. TLS connection establishes fully. HTTP data requests immediately generate a TCP RST.</i><br><br>3. I believe Wireshark can do this (I'm more familiar with using openssl<br>s_client), but I would strongly suggest checking what the SSL<br>certificate is that the server returns.<br><br>It's very possible that the SSL cert the Apple servers use has expired<br>and the underlying client application lacks proper error handling /<br>display to handle this situation (e.g. popping up a UI telling the user<br>that the comm protocol failed due to SSL library errors, and displaying<br>that error result).  You might be surprised how often this happens<br>(companies not monitoring/tracking SSL cert expiry dates) -- it's<br>extremely common.<br><br><i>Sigh... Went back and tried pcap on a refresh several times, and got a ton of out of order and duplicate packets every time, followed by a fail like previous. I never saw the certificate but I did see several "Encrypted Alert" messages that Wireshark would not further detail. <br><br>Jeremy, I will send you the small pcap off list if you don't mind, and maybe you can decipher what is going on.<br><br>THANKS!</i><br><br>JK<br>-- <br>| Jeremy Chadwick                                   jdc@koitsu.org |<br>| UNIX Systems Administrator                <a href="http://jdc.koitsu.org/">http://jdc.koitsu.org/</a> |<br>| Making life hard for others since 1977.             PGP 4BD6C0CB |<br><br>On Fri, Jul 11, 2014 at 02:18:31PM -0400, J Kibler via Outages wrote:<br>> Hi,<br>> <br>> Is anyone seeing a partial outage of podcasts using iTunes on a Mac?<br>> <br>> Several of my subscriptions have not updated since the day before<br>> yesterday and the subscription shows an explanation point inside the<br>> circle by the podcast name in list view. Running Wireshark and doing a<br>> "refresh podcast" on those individual podcasts, I see a successful TLS<br>> connection followed by a series of HTTP RSTs and the connection being<br>> torn down. Examples of podcasts not updating include:<br>>    *KQED's Forum   *NPR Topics: Technology Podcast *60-Second Science  <br>> (SciAm)      *Discovery    (BBC)<br>>       My other dozen or so podcasts are updating normally.<br>> Any ideas?<br>> <br>> TIA!<br>> <br>> JK<br>> <br><br>> _______________________________________________<br>> Outages mailing list<br>> Outages@outages.org<br>> <a href="https://puck.nether.net/mailman/listinfo/outages">https://puck.nether.net/mailman/listinfo/outages</a></blockquote></span>