Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #35616 > unrolled thread

SSL trends

Started byRoedy Green <inquiry@mindprod.com>
First post2016-09-15 13:55 -0700
Last post2016-09-19 23:15 +0200
Articles 7 — 3 participants

Back to article view | Back to comp.lang.java.programmer


Contents

  SSL trends Roedy Green <inquiry@mindprod.com> - 2016-09-15 13:55 -0700
    Re: SSL trends Arne Vajhøj <arne@vajhoej.dk> - 2016-09-15 20:18 -0400
      Re: SSL trends Roedy Green <inquiry@mindprod.com> - 2016-09-22 21:58 -0700
        Re: SSL trends Arne Vajhøj <arne@vajhoej.dk> - 2016-09-24 18:25 -0400
      Re: SSL trends Roedy Green <inquiry@mindprod.com> - 2016-09-22 22:02 -0700
        Re: SSL trends Arne Vajhøj <arne@vajhoej.dk> - 2016-09-24 18:29 -0400
    Re: SSL trends Silvio <silvio@internet.com> - 2016-09-19 23:15 +0200

#35616 — SSL trends

FromRoedy Green <inquiry@mindprod.com>
Date2016-09-15 13:55 -0700
SubjectSSL trends
Message-ID<df2mtb9j123dd3kqhlsd6faip00ub1j5kp@4ax.com>
There has been a trend to flip from http: to https:.  Google has been
pushing this.

However there are a set of headaches that come with the transition.
1. clients must have the root cert installed
2. certs expire
3. there is more CPU overhead
4. caching is turned off
5. certs often do not work for some people. People can't access the
website to complain.

In the last week, I have noticed a trend in the other direction.

[toc] | [next] | [standalone]


#35617

FromArne Vajhøj <arne@vajhoej.dk>
Date2016-09-15 20:18 -0400
Message-ID<nrfdo1$1008$1@gioia.aioe.org>
In reply to#35616
On 9/15/2016 4:55 PM, Roedy Green wrote:
> There has been a trend to flip from http: to https:.  Google has been
> pushing this.
>
> However there are a set of headaches that come with the transition.
> 1. clients must have the root cert installed

All normal browsers should have that. Not a problem.

> 2. certs expire

Should be handled via OS/browser updates. Nobody should surf
the internet with a OS/browser that is not being updated. Not
a problem

> 3. there is more CPU overhead

Usually there are plenty of CPU available client side. Not a problem.

> 4. caching is turned off

Wrong.

> 5. certs often do not work for some people. People can't access the
> website to complain.

That is very rare - not "often".

Arne

[toc] | [prev] | [next] | [standalone]


#35631

FromRoedy Green <inquiry@mindprod.com>
Date2016-09-22 21:58 -0700
Message-ID<q7d9ub143gumfitf9ot0r2u7phsdkeg16a@4ax.com>
In reply to#35617
On Thu, 15 Sep 2016 20:18:10 -0400, Arne Vajhøj <arne@vajhoej.dk>
wrote:

>> However there are a set of headaches that come with the transition.
>> 1. clients must have the root cert installed
>
>All normal browsers should have that. Not a problem.

For example, you have to manually install the root certs for Gandi and
Let's encrypt.  Also there are displutes with China. You have to
install some of them manually.  I had to import 114 of them into
cacerts. Java's list is quite sparse.

>> 2. certs expire

>
>Should be handled via OS/browser updates. Nobody should surf
>the internet with a OS/browser that is not being updated. Not
>a problem
The problem is the people running the server fail to notice their cert
is about to expire. It takes them about a week get a new one. I
monitor quite a number of websites as part of looking for broken links
on my site.  This is now the #1 cause of broken links.  I email them.
They always seem surprised and even incredulous.

[toc] | [prev] | [next] | [standalone]


#35641

FromArne Vajhøj <arne@vajhoej.dk>
Date2016-09-24 18:25 -0400
Message-ID<ns6ugq$ima$1@gioia.aioe.org>
In reply to#35631
On 9/23/2016 12:58 AM, Roedy Green wrote:
> On Thu, 15 Sep 2016 20:18:10 -0400, Arne Vajhøj <arne@vajhoej.dk>
> wrote:
>>> However there are a set of headaches that come with the transition.
>>> 1. clients must have the root cert installed
>>
>> All normal browsers should have that. Not a problem.
>
> For example, you have to manually install the root certs for Gandi and
> Let's encrypt.  Also there are displutes with China. You have to
> install some of them manually.  I had to import 114 of them into
> cacerts. Java's list is quite sparse.

Browsers are kept uptodate automatically.

Maybe Java is different.

But don't expect the web to prioritize Java programs fetching
pages.

Browsers must outnumber Java programs by 4-5 orders of magnitude.

>>> 2. certs expire
>
>>
>> Should be handled via OS/browser updates. Nobody should surf
>> the internet with a OS/browser that is not being updated. Not
>> a problem
> The problem is the people running the server fail to notice their cert
> is about to expire. It takes them about a week get a new one. I
> monitor quite a number of websites as part of looking for broken links
> on my site.  This is now the #1 cause of broken links.  I email them.
> They always seem surprised and even incredulous.

That happens occasionally.

But you can chose to accept anyway.

Arne

[toc] | [prev] | [next] | [standalone]


#35632

FromRoedy Green <inquiry@mindprod.com>
Date2016-09-22 22:02 -0700
Message-ID<lkd9ub1orkq61a14dmu1h5usnd40951meo@4ax.com>
In reply to#35617
On Thu, 15 Sep 2016 20:18:10 -0400, Arne Vajhøj <arne@vajhoej.dk>
wrote:

>> 4. caching is turned off
>
>Wrong.

If you have two users accessing the same page, but it is a secret what
they are accessing, how can a cache possibly share that page?

Obviously you can do things like disk caching on the server using the
unencrypted form, but once the page is encrypted, e.g. the first page
of an online newspaper, it is not going to get cached by a the IAP
from its local cache.

[toc] | [prev] | [next] | [standalone]


#35642

FromArne Vajhøj <arne@vajhoej.dk>
Date2016-09-24 18:29 -0400
Message-ID<ns6uo2$isd$1@gioia.aioe.org>
In reply to#35632
On 9/23/2016 1:02 AM, Roedy Green wrote:
> On Thu, 15 Sep 2016 20:18:10 -0400, Arne Vajhøj <arne@vajhoej.dk>
> wrote:
>
>>> 4. caching is turned off
>>
>> Wrong.
>
> If you have two users accessing the same page, but it is a secret what
> they are accessing, how can a cache possibly share that page?
>
> Obviously you can do things like disk caching on the server using the
> unencrypted form, but once the page is encrypted, e.g. the first page
> of an online newspaper, it is not going to get cached by a the IAP
> from its local cache.

The browser can and do cache pages retrieved via HTTPS.

It can be cached server side as well. That is done by terminating
SSL in front on the cache server. That is quite common.

The only cache that is not possible is an intermediate
cache somewhere in the middle of the network. I don't think
I have heard about that being used on this side of year 2000.

Arne

[toc] | [prev] | [next] | [standalone]


#35625

FromSilvio <silvio@internet.com>
Date2016-09-19 23:15 +0200
Message-ID<57e05582$0$4256$e4fe514c@newszilla.xs4all.nl>
In reply to#35616
On 09/15/2016 10:55 PM, Roedy Green wrote:
> There has been a trend to flip from http: to https:.  Google has been
> pushing this.
>
> However there are a set of headaches that come with the transition.
> 1. clients must have the root cert installed
> 2. certs expire
> 3. there is more CPU overhead
> 4. caching is turned off
> 5. certs often do not work for some people. People can't access the
> website to complain.
>
> In the last week, I have noticed a trend in the other direction.
>

I disagree. Unencrypted protocols where a mistake from day one and most 
of them (like FTP and plain text SMTP) have long been abandoned in favor 
of more secure alternatives. There is absolutely no excuse for using 
HTTP over the public Internet like there is no excuse for using obsolete 
client software on that same Internet.

The cited problems are either insignificant (1, 2, 3) or wrong (4, 5).

The move to HTTPS was long overdue. It has the additional advantage of 
rapidly pushing out old clients. IE6, old Java versions and the like 
have been holding back the Internet for much too long.

Silvio

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.java.programmer


csiph-web