When connecting to an unknown unsecured wireless network, is it possible for someone to capture a header and resend it even if it's over https?
For example I login on an ipod or on a computer and connect to a server through https and password auth. Although anyone monitoring the transmission could not get hold of my password since it's encrypted, could they just capture the header and resend it 5mins later to logon again without even knowing the password?

how would you establish that is HTTP over SSL?
how would you establish that is a login request inside it?
and then, even if that could have possibly work out(in fact it won't) then what will you do later? okay you resend that packet then what?

That's the bit I don't understand I guess - if they could resend the packet, what would stop that from logging into the site again?

So, anything sent over HTTPS or SSL on a public wifi is secure enough for a hacker not to get your information? It's just HTTP (non encrypted) that is the issue.

Yes.

Yes, there's nothing stopping them from doing that. Having it work properly, OTOH, is a different story. What you're describing here is called a replay attack, and SSL does incorporate countermeasures for it. To read a general description of them, I recommend the paper titled Analysis of the SSL 3.0 Protocol, written by Wagner and Schneier. The relevant part is section 3.5, but you'll probably want to look at the rest too for context.

Why might it not work?
I can understand how sessions would prevent the login but sessions also have a timeout period. For example, if I logged in and then didn't log out, the attacker could just send the replay and it would presumably still use the current session ID?

If SSL has this:
SSL protects against replay attacks by including an implicit sequence number in the MACed data.
When is the number sent is it on the first request to a login page. If you leave the login page open for 24hrs, does the sequence number remain the same and what prevents it from being reused?

Also, how might this affect an application on an ipod, which presumably uses secure sockets rather than HTTPS?
I know an ipod app that has a login but no logout button although it requires you to relogin everytime you connect so perhaps it uses a new session or something else during the transfer.

Whether something is "secure enough" or not is completely subjective without a checklist.

Look at it this way, though: E-commerce itself pretty much depends on the security provided by SSL, and it's a protocol which has received tons of peer-review over the years. That said, there have indeed been flaws found in SSL implementations (some of them have even made the mainstream news IIRC, so it should be an easy Google), so don't expect perfection.

The sequence would be broken.

The counters are increased for every message which is sent.

Not sure what you mean (HTTPS is HTTP sent over SSL/TLS).

But what is the sequence and how long does it persist for.
So, I connect to a site via HTTPS and it sends me a MAC sequence.
How does it know to keep the key indefinitely if sessions are not used?

MAC counters?

Yes, so an ipod app, which presumably connects via SSL, it uses the same SSL MAC key and that is changed every time a new connectgion is made? What happens to the old key and how long does the server wait before deleting the key?

SSL Overview from the Customer's Browser viewpoint

1. Browser checks the certificate to make sure that the site you are connecting to is the real site and not someone intercepting.
2. Determine encryption types that the browser and web site server can both use to understand each other.
3. Browser and Server send each other unique codes to use when scrambling (or encrypting) the information that will be sent.
4. The browser and Server start talking using the encryption, the web browser shows the encrypting icon, and web pages are processed secured.

How long do those unique codes persist for because the web browser sending pages is static not a dynamic connection.

No. Each message it sends you has a sequence number in it. The same goes for the messages you send to the server. Each of you has your own set of sequence numbers. They are used until the next key exchange.

No. Sequence number counters.

So, the server remembers the sequence number indefinitely?

No. Like I said before, sequence numbers are only used until the next key exchange. If the SSL session times out or is deliberately terminated, that means you need to exchange keys again, and a new sequence is started.

So, how come you can get to a site with the login box say https://thisite.com/login.php and then hibernate your computer for a day or a week, yet when you turn it back on, you can login from the same page?
For that to work, the server has to store the sequence numbers for a long time...

To conclude, from what you see on the screen, that no re-auth goes on behind the screens is not a good observation. Better try something like tcpdump with a 'host thisite.com and port 443' filter and 'openssl s_client -connect https://thisite.com/login.php -state -nbio 2>&1' instead. You should see the whole network and SSL handshaking done again after coming out of hibernation.

No, the session is free to be timed out, and you'll just need you to do another SSL handshake with the server in that case (which is something transparent to the user). unSpawn has provided you with the means to see things with your own eyes, and I really can't do any better than that.