When “It’s Down” Isn’t the Whole Story: A TLS Handshake Mystery

A TLS handshake that returned zero bytes, a browser that lied about it being fixed, and a Contact Form 7 issue that turned out to be someone else's mail server all along — a full diagnostic trail from symptom to resolution.

Fresh off patching CVE-2026-63030 (the “wp2shell” SQL injection vuln — more on that in a future post), I sat down to check on ny2honolulu.com and got hit with a wall: ERR_CONNECTION_CLOSED. Browser said the site closed the connection. My iPhone, on a different network, loaded the site just fine. That mismatch — desktop broken, phone fine — is exactly the kind of clue that either means “check your own network” or “something much more specific is going on.” Turned out to be the latter, and chasing it down was a good reminder that the obvious explanation isn’t always the right one.

The Symptom

  • Browser: ERR_CONNECTION_CLOSED on https://ny2honolulu.com
  • iPhone (different network): loaded perfectly
  • WP Admin (/wp-admin): unreachable — same as the front end

First instinct: my home IP got blocked by a WAF or security plugin, probably as fallout from the CVE patch work (SFTP uploads, admin logins while troubleshooting a failed auto-updater). Reasonable theory. Time to test it properly instead of assuming.

Building the Diagnostic Chain

Rather than guess, I ran a sequence of tests, narrowing the possibility space one layer at a time:

1. Is my connection broken in general?

bash

curl -v https://google.com

Full TLS 1.3 handshake, valid cert, HTTP/2 301 response. My connection, DNS, and TLS stack were all healthy. Ruled out: local network/ISP issue.

2. Is it DNS-specific to ny2honolulu.com?

bash

curl -v --resolve ny2honolulu.com:443:209.17.116.165 https://ny2honolulu.com

Same failure even hitting the IP directly with the hostname forced via --resolve. Ruled out: DNS resolution.

3. What does the raw TLS handshake actually look like?

bash

openssl s_client -connect 209.17.116.165:443 -servername ny2honolulu.com

This was the key result:

SSL handshake has read 0 bytes and written 1555 bytes
error:0A000126:SSL routines::unexpected eof while reading

My Client Hello went out (1555 bytes sent) — and the server sent back nothing. Not a rejection, not an alert, just silence until the connection died. That’s the signature of something actively intercepting and dropping the connection, not a misconfigured server.

4. Is it TLS-specific, or is the whole IP blocked?

bash

curl -v http://ny2honolulu.com

Port 80 (plain HTTP) worked perfectly — full page load, WordPress content, headers, everything. This was the turning point: a full IP ban would kill port 80 too. This was surgical — port 443 only.

The Verdict, Before Contacting Anyone

By the time I reached out to support, I already knew:

  • Not a DNS issue
  • Not a full site outage (content was healthy, WordPress was serving fine on port 80)
  • Not a local network/ISP problem (google.com and even apt update against a dozen different repos worked flawlessly)
  • Specifically: TLS/port 443 connections were being silently dropped after the Client Hello, every time, from my connection

That’s a precise, falsifiable finding — not “the website seems down,” but “here is exactly what’s broken and here’s the proof.”

Getting It Escalated

Network Solutions’ live chat happened to display an active outage notice for “intermittent outage for websites and web services” right as I connected — which lined up with what I was seeing. I gave the agent the technical rundown (IP, symptom, curl/openssl evidence, and what was already ruled out). She reproduced the issue on her end too, which was the real confirming detail — it meant this wasn’t unique to my home connection at all, just something I’d happened to hit first.

Case #E-566554 got escalated to their senior technical team with a stated 24–72 hour resolution window. About 18 hours later, the fix landed.

Confirming the Fix — the Right Way

Here’s the part worth remembering for next time: the browser is not a reliable source of truth for “is this actually fixed.” At one point mid-incident, my browser rendered the homepage just fine, cache and all, while curl against the same URL still failed identically. Browsers cache aggressively and don’t always reflect the live state of a connection.

The only way to know for sure: re-run the same curl -v test that failed originally.

bash

curl -v https://ny2honolulu.com

Post-fix result:

* TLSv1.3 (IN), TLS handshake, Server hello (2):
...
* SSL certificate verified via OpenSSL.
< HTTP/1.1 200 OK
< Server: openresty/1.25.3.1
< Strict-Transport-Security: max-age=31536000
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN

Full handshake, valid Network Solutions cert (valid through Nov 2026), clean 200 response — and interestingly, the response now includes security headers (HSTS, X-Content-Type-Options, X-Frame-Options) that weren’t present before the incident. Whatever they fixed on the WAF/proxy layer, they tightened things up while they were in there.

Lessons Learned

  1. “Works on my phone” is a data point, not a diagnosis. Different network, different IP — useful for narrowing scope, not for concluding what’s actually broken.
  2. Test each layer independently. DNS, TCP, TLS, and HTTP are different failure domains. A tool that “hangs” or “fails” could be stuck at any one of them — find out which.
  3. openssl s_client tells you things curl summarizes away. The “0 bytes read, 1555 bytes written” detail was the single most diagnostic piece of information in the whole incident — it’s the difference between “server rejected me” and “something ate my request silently.”
  4. Compare ports, not just protocols. Testing port 80 alongside port 443 turned “the site might be down” into “this is specifically about TLS,” which is a much more useful thing to hand to support.
  5. Don’t trust the browser to confirm a fix. Always re-run the exact failing command, not a visual check, before declaring victory.

Bonus: The Package Updater Ghost

Unrelated wrinkle during the same window — Debian’s GUI Package Updater kept showing “7 updates available,” and installing would silently do nothing, over and over, all day. apt update from the terminal ran clean the whole time (29.3 MB fetched, no errors), and lsof on the dpkg lock showed nothing holding it. It resolved itself the moment I went to demonstrate the problem — almost certainly a stale lock or a stuck background process (possibly unattended-upgrades) that cleared on its own. Filed under “weird but not worth chasing further,” since it didn’t recur.

Addendum: Fixing the Contact Form While I Was In There

While chasing the TLS incident, I’d been using a plain mailto: link on the homepage as a workaround, because Contact Form 7 had given me trouble months earlier and I never tracked down why. With the mail pipeline back in the spotlight, it seemed like the right time to revisit it.

Turned out CF7 was never actually broken — the form itself validated clean (WordPress’s built-in “Validate Contact Form 7 Configuration” tool found nothing wrong), and the Mail tab was correctly wired to send from and to my domain address. The real culprit was almost certainly the same thing that’s caused half the mail headaches on this site: unreliable delivery before WP Mail SMTP was properly configured and authenticated.

To confirm, I ran two tests:

  1. WP Mail SMTP’s built-in test email — sent successfully and arrived in my inbox.
  2. A live end-to-end form submission — filled out the actual Contact Form 7 form on a fresh page and confirmed the email landed, footer and all: “This e-mail was sent from a contact form on ny2honolulu.”

Both worked cleanly. So I:

  • Built a dedicated /contact page with the form, plus a short intro line setting expectations (reply time, no cold pitches)
  • Replaced the homepage’s mailto: button with a “Get in Touch” button linking to that page

The mailto: approach technically worked, but it handed control of the experience to whatever mail client (or lack thereof) happened to be configured on a visitor’s machine — sometimes Gmail, sometimes Outlook, sometimes a “choose an app” dialog that looks like a broken link. A form removes that variable entirely.

Lesson learned: when a piece of infrastructure “doesn’t work” and you route around it instead of diagnosing it, revisit that decision once you’ve fixed something adjacent. The actual root cause (mail delivery) had already been solved by earlier SMTP work — the form itself was never the problem.

Case reference: Network Solutions Escalated Case #E-566554. Full diagnostic transcript (curl/openssl output, live chat log) available on request.