In SSL, things go like that: the client looks up the server name in the DNS; then it connects to the IP address the DNS came up with; then the SSL handshake occurs, during which the server sends its certificate. Note that the actual URL has not been sent anywhere at that point, only the server name; so we can ignore the URL for the diagnosis.
Since the problem impacts several machines with distinct OS and browsers, we can probably rule out browser and OS bugs.
Google, Barnes and Noble, Facebook... are human creation which, as such, are imperfect and may fail occasionally; but it is quite improbable that they all fail simultaneously.
If you are the target of a Man-in-the-Middle attack, then the attacker is singularly incompetent. That's quite improbable too.
To sum up, the problem is probably somewhere between your router and your ISP. The symptoms you observe are coherent with the hypothesis that the TCP connection from your browser, formerly directed at
www.google.com, ends up on Apple's iCloud servers. A first potential scenario is the following:
Your router is a DNS relay. Over DHCP, it actually configures your home machines to use the router as DNS server, and that router will feed on the external DNS server you configured (Google's DNS server). In that case, if the router mixes its internal tables (due to a software bug or bad RAM), then it may gives wrong IP addresses to your machines.
In that scenario, the problem is not limited to SSL. Indeed, when the browser wants to connect to any server, it asks for the server name but not for the port or protocol. Therefore, if that hypothesis is correct, then non-SSL, plain HTTP connections should also occasionally fail. For instance, if your connection to
www.facebook.com is redirected to the IP address of
www.google.com, you will get a Google answer (actually a redirect to Google's main page), and nothing Facebook-like.
If only your SSL connections have trouble, then this is not a DNS issue. This would point to a second potential scenario:
Your ISP has some problem with its dynamic routing. It tries to route traffic optimally, moving packets between several destinations. These routing decision can be port-specific, thus explaining why the problem occurs with SSL only. For some reason (possibly bad RAM again, in one of the ISP routers), packets can get misdirected.
I have known an old Cisco router (with bad RAM) which behaved a bit like that. When a router processes an IP packet, it must copy and partially modify the header (at least to modify the TTL) so bugs in the router can result in destination address being mangled.
This scenario has a variant in which your router has bad RAM (again...) and trips on its own feet when doing NAT.
To further diagnose the problem:
When the problem occurs, from the same machine, do a
nslookup www.google.com (if you wanted to contact Google but was redirected somewhere else) then
openssl s_client -connect www.google.com:443 (using the OpenSSL command line tool -- if you use Linux or MacOS X, then you already have it). This will tell you what IP address is returned by the DNS, and what certificate is returned by the server which purportedly answers at that address.
If the problem is intermittent (i.e. the browser connection fails, but trying again immediately works), try running a network capture tool like Wireshark or Network Monitor to observe exactly what went on when the problem occurred. You will see the IP addresses as seen from your machine.
Change your home router. For instance, borrow an old router from a friend, or buy a new one (these cost 40$). If the problem is at your ISP, then the ISP support staff will probably first claim that your router is at fault, so this step cannot really be avoided anyway. If changing the router removes the issue, then you know that bad RAM stroke once again.