It sounds like you are describing an "implementation problem" (i.e., OpenSSL's code sucks).
But then you suggest this could be a reason to throw out the notion of "ciphersuite flexibility".
Aren't these two separate things?
Perhaps the flexibility is good.
Maybe the problem is one of complexity and quality control.
Too many ciphers, and incoporating ones of dubious quality.
I still haven't seen anyone mention the other SSL libraries, e.g.,
axssl,
polarssl,
matrixssl,
etc.
As for CA "infrastructure", what if the user uses OpenSSL's ca function?
She creates her own CA certificate and key and installs it on her device.
Then she downloads a website's certificate, signs it and installs it on her device.
Regardless of whether a wesbite has a paid-for certificate from a commercial "CA authority", she needs to make the final decision whether or not to trust it.
The user is the ultimate arbiter of which website certificates she wants to sign and install. (Not browser authors.)
Websites just need a central repository to publish their certificates.
They already do this for their "domain names" by having them published in a publicly accessible zone file (ideally, the user can download the zone file, as well as query it piecemeal over a network).
We as users trust that these zone files are accurate: specifically, we assume the IP addresses for the website's nameservers are correct.
Prior to TLS 1.2, all of the mainstream ciphersuites are bad.
The fact that you have to upgrade to TLS 1.2, which includes more than just new ciphersuites, somewhat counterfeits the idea that the ciphersuite mechanism provided much protection.
Ultimately, the protocol might have been just as well off by defining a single ciphersuite and accepting that a break in that ciphersuite would necessitate a protocol update.
But then you suggest this could be a reason to throw out the notion of "ciphersuite flexibility".
Aren't these two separate things?
Perhaps the flexibility is good.
Maybe the problem is one of complexity and quality control.
Too many ciphers, and incoporating ones of dubious quality.
I still haven't seen anyone mention the other SSL libraries, e.g., axssl, polarssl, matrixssl, etc.
As for CA "infrastructure", what if the user uses OpenSSL's ca function?
She creates her own CA certificate and key and installs it on her device.
Then she downloads a website's certificate, signs it and installs it on her device.
Regardless of whether a wesbite has a paid-for certificate from a commercial "CA authority", she needs to make the final decision whether or not to trust it.
The user is the ultimate arbiter of which website certificates she wants to sign and install. (Not browser authors.)
Websites just need a central repository to publish their certificates.
They already do this for their "domain names" by having them published in a publicly accessible zone file (ideally, the user can download the zone file, as well as query it piecemeal over a network).
We as users trust that these zone files are accurate: specifically, we assume the IP addresses for the website's nameservers are correct.