Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #35616 > unrolled thread
| Started by | Roedy Green <inquiry@mindprod.com> |
|---|---|
| First post | 2016-09-15 13:55 -0700 |
| Last post | 2016-09-19 23:15 +0200 |
| Articles | 7 — 3 participants |
Back to article view | Back to comp.lang.java.programmer
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
| From | Roedy Green <inquiry@mindprod.com> |
|---|---|
| Date | 2016-09-15 13:55 -0700 |
| Subject | SSL 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]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2016-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]
| From | Roedy Green <inquiry@mindprod.com> |
|---|---|
| Date | 2016-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]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2016-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]
| From | Roedy Green <inquiry@mindprod.com> |
|---|---|
| Date | 2016-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]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2016-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]
| From | Silvio <silvio@internet.com> |
|---|---|
| Date | 2016-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