It works the opposite of what you think it does.
"Enable TLS" merely allows the TLS module to be used to open secure connections, it doesn't force people to not use insecure connections. Some people may not trust TLS from a calculator and so may want to disallow that entirely. Having Enable TLS disabled means the TLS module will disallow the use of TLS on connections, meaning you also cannot connect to anything that requires it.
If people think that setting isn't needed, I'll remove it, but it's there for a bit more user control.

https://i.imgur.com/SMSzNbg.jpeg

New test UI. From the main app, it will be possible to run a few tests.
Testing reveals that it..works, but bottlenecks at around 8-10 rapid refreshes (consistent with, you know, serving HTTP from a calculator...small TCP window sizes, small max TCP queue, small max TCP PCB slots). However, with a sizeable drop in WAIT_TIME, resources free up quickly, recovery is more sane and more stable.

https://i.imgur.com/MPYvlgw.mp4

A recording of the several network tests now implemented within lwIP.
Didn't run HTTP because there's no... verify it works on calc. You'd just go to the IP address the calc gives you.
Ping doesn't work yet.
NTP works... sometimes.

Update

I have published a pre-release of lwIP-CE.
https://github.com/cagscalclabs/lwip-ce/releases/tag/v1.0-pre
This pre-release is intended to let people experiment with the existing network tests in their own environments to confirm stability. People may also spin up their own tests if they wish. Report any issues in this thread or in the discussion on Github:
https://github.com/cagscalclabs/lwip-ce/discussions/38

TODO:
Wire in x25519 from the contest, and complete TLS support
Dylib/entrypoint support

Update

A few things to report.
Firstly, PT_ was the winner of the x25519 contest. So congrats to him. Algorithm times to about 5 seconds, and he and ti_kid seem to continue to work on improvements. I much appreciate the work on that, even though it did come with a non-trivial prize.

And as of that, with the exception of the slight snag of the virtuals + app quirk, we should now have the ability for the TI-84+ CE to implement the entire TLS 1.3 client-side without issue.
That means:

Code:

Additionally everything that is in CryptX will also be exposed within lwip=>tls. You will no longer need CryptX once this is released as a dylib.

There is a TLS test now added to the configuration wizard within the app. It lets you open a TLS connection to example.com and verify the response.

Also also, I reworked the ASN.1 parser system (it was a bit unintuitive), and broke the keyobject module into pkcs8 and x509 modules for simplicity and code separation. Here's a screenshot of the two new unit tests on CEmu.

And now I have a question. Does anyone specifically want me to implement within lwIP a viewer UI for showing the DER tree for keyfiles? As in, you can scroll through an iteration of TLV pairs, view how the bytes break down, etc? Or is the parser logic enough for people?

Does this mean that we can access the internet on the CE without any specialized hardware now?

You'd need an adapter and an Ethernet cable.
USB mini to USB A adapter => connect to calc
USB A to Ethernet adapter => connect to the above adapter
Ethernet cable => connect to router and above adapter

You could also connect via Ethernet to an Ethernet to WiFi-N adapter, but you'd need one with WiFi Protected Setup because there's no drivers for actually interacting with the adapter from the calc.

Update

I endeavored to add a timing consistency test to the array of unit/module tests for lwIP. The test is under tests/tls_timing.
https://github.com/cagscalclabs/lwip-ce/actions

It checks all primitives or modules that require constant time. This is:
random_bytes, secure_compare_bytes, SHA-256 (& HMAC), AES-CBC, AES-GCM, HKDF, PBKDF2, and x25519. RSA is currently omitted as I try to figure out what vectors it would need.

This test takes ~30 minutes to run via the cemu-autotester and would undoubtedly take hours to run on a calculator; that being said I encourage people to run it on their calculators if you can spare the time. I want to see:
1. If it fails a specific test category for anyone
2. What the averages are for specific tests

For #2, build the test with with the -DTLS_TIMING_VERBOSE compiler flag. That will make it print stability and differential data so I can review to confirm if our thresholds (particularly for differentials) are sane. Please post the verbose output to this thread, alongside your hardware revision and OS version, if you run it that way.

What do the two tests mean?
We test timing in two categories: stability, which is meant to capture jitter, and differential, which is meant to capture differences in timing based on a class of input.

For the stability test: Identical inputs are executed repeatedly. The primitive passes if the standard deviation of CPU cycle counts remains below 1% of the mean runtime. Any primitive exceeding this threshold fails.

For the differential test: Inputs are grouped into the following structural classes: best-case, worst-case, random, edge-case. Each class is executed multiple times. If a single class exhibits a statistically consistent runtime deviation from the others (>=75% of runs trending higher in the same direction beyond configured cycle thresholds), the primitive fails. The current thresholds are printed in the job summary for the test on github.