9 bad.horse (162.252.205.130) 171.987 ms 171.961 ms 172.387 ms
10 bad.horse (162.252.205.131) 177.009 ms 176.570 ms 177.807 ms
11 bad.horse (162.252.205.132) 182.312 ms 181.682 ms 181.581 ms
12 bad.horse (162.252.205.133) 186.254 ms 186.723 ms 186.896 ms
13 he.rides.across.the.nation (162.252.205.134) 191.581 ms 191.995 ms 192.539 ms
14 the.thoroughbred.of.sin (162.252.205.135) 196.768 ms 196.683 ms 197.056 ms
15 he.got.the.application (162.252.205.136) 201.184 ms 201.550 ms 201.829 ms
16 that.you.just.sent.in (162.252.205.137) 226.084 ms 206.611 ms 209.440 ms
17 it.needs.evaluation (162.252.205.138) 214.950 ms 211.952 ms 212.041 ms
18 so.let.the.games.begin (162.252.205.139) 216.997 ms 216.730 ms 217.574 ms
19 a.heinous.crime (162.252.205.140) 222.739 ms 313.316 ms 221.550 ms
20 a.show.of.force (162.252.205.141) 227.455 ms 226.936 ms 227.003 ms
21 a.murder.would.be.nice.of.course (162.252.205.142) 232.136 mse 232.144 ms 231.795 ms
ie22 bad.horse (162.252.205.143) 237.418 ms 320.457 ms^U
237.265 ms
23 bad.horse (162.252.205.144) 282.589 ms 241.483 ms 299.596 ms
24 bad.horse (162.252.205.145) 313.476 ms 246.855 ms 292.823 ms
25 he-s.bad (162.252.205.146) 313.384 ms 277.220 ms 345.561 ms
26 the.evil.league.of.evil (162.252.205.147) 327.858 ms 256.816 ms 279.833 ms
27 is.watching.so.beware (162.252.205.148) 313.327 ms 261.990 ms 287.819 ms
28 the.grade.that.you.receive (162.252.205.149) 267.278 ms 267.262 ms 267.032 ms
29 will.be.your.last.we.swear (162.252.205.150) 352.531 ms 304.294 ms 271.968 ms
30 so.make.the.bad.horse.gleeful (162.252.205.151) 282.465 ms 278.175 ms 276.852 ms
31 or.he-ll.make.you.his.mare (162.252.205.152) 297.755 ms 281.298 ms 282.081 ms
32 o_o (162.252.205.153) 288.199 ms 286.632 ms 286.601 ms
33 you-re.saddled.up (162.252.205.154) 389.436 ms 327.868 ms 296.183 ms
34 there-s.no.recourse (162.252.205.155) 333.364 ms 328.371 ms 300.595 ms
35 it-s.hi-ho.silver (162.252.205.156) 326.765 ms 327.759 ms 313.318 ms
36 signed.bad.horse (162.252.205.157) 311.141 ms 330.010 ms 419.000 ms
You were told to use http. It's your own fault for escalating to https
with no representation that a working https site was available at that
URL.
And then of course there's the completely fair question of whether
it's sensible to forcibly deprecate older security protocols when
accessing information that's also offered over fully unencrypted
channels. Confidentiality, Integrity AND Availability. Lotta wounds to
availability from forced deprecation. Whole lot.
Also, as long as we're pointing out faults in others' behavior: top
posting and hiding the poster's identity, both violations of the use
conventions on this list.
The software has no concept of what the data is and must provide the user the desired confidentiality and integrity, which unfortunately means forced deprecation and possible lack of Availability. This also applies to features such as HTTPS RRs in DNS that aren’t always configured correctly and ECH prohibits fallback when it breaks; choosing security over availability. I do wish browsers were better at explaining why something breaks, though. It’s especially bad with embedded content where it just doesn’t work and even dev tools might show “server disconnected prematurely” or something similar. Jack
Which is why the software shouldn't be making a hard decision about
appropriate cryptography. The users on the two ends, the folks who do
know what the data is, should have the final say. The software should
set sensible defaults and then let those users decide what to do about
the large and growing gap of failure between the current default and
the often still allowed unencrypted plain text.
That "curl https://enemieslist.com" returns a fault is not
unreasonable. That "curl --insecure https://enemieslist.com" also
fails reflects faulty thinking on the part of alleged security
experts.
My personal pain point is out of band access to older servers. They're
well past the manufacturer's maintenance so there are no more software
updates. I can use nice modern VPN software to secure the channel
between me and their LAN, but I have to maintain obsolete versions of
web browsers and their dependent libraries along with obsolete
versions of Java because the modern ones won't connect. I'd rather
have less obsolete bug ridden software around, but the self-appointed
security experts have stolen that choice from me.
Which is why the software shouldn't be making a hard decision about
appropriate cryptography. The users on the two ends, the folks who do
know what the data is, should have the final say. The software should
set sensible defaults and then let those users decide what to do about
the large and growing gap of failure between the current default and
the often still allowed unencrypted plain text.
Most users don't have any idea and would allow an attacker to compromise their bank connection if given the choice. The defaults are designed to protect the majority?
That "curl https://enemieslist.com" returns a fault is not
unreasonable. That "curl --insecure https://enemieslist.com" also
fails reflects faulty thinking on the part of alleged security
experts.
I suspect --insecure has special meaning and shouldn't be overloaded to include anything that is "insecure". However, curl depends on the underlying libraries, and I believe it was those libraries that are being compiled and installed with older stuff disabled. A quick search shows you have to do custom builds to enable on any current system.
My personal pain point is out of band access to older servers. They're
well past the manufacturer's maintenance so there are no more software
updates. I can use nice modern VPN software to secure the channel
between me and their LAN, but I have to maintain obsolete versions of
web browsers and their dependent libraries along with obsolete
versions of Java because the modern ones won't connect. I'd rather
have less obsolete bug ridden software around, but the self-appointed
security experts have stolen that choice from me.
In my experience, except for Java incompatibilities itself, you can usually tweak the configuration and exception rules to get Java to connect and accept older signed packages. Sometimes you have to retweak after an upgrade. FireFox appears to have quite a few options in about:config to enable older stuff and also supports exception lists for some things.
Of course, my experience is limited, and I may not be nearly as archaic as you.
I see no issue with the server user deciding that it won't converse
with a client user beneath some level of cryptographic quality. The
server operator has a reasonable idea how sensitive his information
is. My bank shouldn't agree to talk to me with TLSv1.0.
Same with the client user. He has a reasonable idea how much care he
wants the data to be given.
My qualm arises when a third party without any knowledge of the data
denies one of the users the ability to meet the other at the other's
lower cryptographic standard. This is damage to availability in a
situation where a meaningful gain to confidentiality or integrity has
not been demonstrated and may be demonstrably false. Such as the
situations described upthread.
My bad, I dropped support for SSL while waiting for a certificate upgrade
and forgot to remove the ssl.conf from sites-enabled while I was waiting; it
isn't really a top priority given that the site only has a few pages, but
it's back on the list of things to fix one of these days. I'd thank you in
person and offlist, but...