SSL Certificates...

On Mon, 30 Nov 2020 19:42:00 -0800, Jeff Liebermann <jeffl@cruzio.com>
wrote:

So basically, what you need to do is check the box on whatever
management interface the web site is using and tell it to translate
*ALL* http:// requests to https:// and I think you\'ll be ok.

You will also need to change all hard coded links, and links to
off-site URL\'s, to https://

Lots of clues on how it\'s done:
<https://www.google.com/search?q=convert+http+to+https+on+server>
This looks tolerable even if it\'s 5 years old:
\"How to Migrate from HTTP to HTTPS - Complete Guide\"
<https://www.keycdn.com/blog/http-to-https>

--
Jeff Liebermann jeffl@cruzio.com
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558
 
On 01/12/2020 03:15, Rick C wrote:
Anyone know about SSL certificates for a web site? I\'m trying to
help a friend who had a web site for his non-profit and I don\'t quite
understand the details. The web hosting provides a certificate which
I copied to Cpanel and it says it is installed, but opening the web
page still reports a problem with security.

At this point I\'m guessing this has to do with the fact that the
certificate is not issued by an authority, but rather self signed. I
found a site that gives out 90 day free certificates and installed
one. Just typing the web site URL doesn\'t show a safe site, but
typing https: manually does, however the web site doesn\'t work
correctly. The initial page has some sort of fancy dancy animated
text that doesn\'t work and you can\'t get past that.

I\'ve reached the limits of what I can figure out. Any web page gurus
out there who can offer some advice?

The web page is coldwatersafety.org

I hope you managed to get the information you need to help your friend
before the thread decayed in traditional s.e.d. style. The conclusion
has to be that you use Let\'s Encrypt for a simple and entirely free
system to get a valid signed SSL certificate - it\'s what just about
everyone else does these days.

As for all the other weaknesses and attack vectors of the internet,
neither you nor anyone else can fix them - you just have to live with them.
 
On Thursday, December 3, 2020 at 1:09:42 PM UTC-5, David Brown wrote:
On 01/12/2020 03:15, Rick C wrote:
Anyone know about SSL certificates for a web site? I\'m trying to
help a friend who had a web site for his non-profit and I don\'t quite
understand the details. The web hosting provides a certificate which
I copied to Cpanel and it says it is installed, but opening the web
page still reports a problem with security.

At this point I\'m guessing this has to do with the fact that the
certificate is not issued by an authority, but rather self signed. I
found a site that gives out 90 day free certificates and installed
one. Just typing the web site URL doesn\'t show a safe site, but
typing https: manually does, however the web site doesn\'t work
correctly. The initial page has some sort of fancy dancy animated
text that doesn\'t work and you can\'t get past that.

I\'ve reached the limits of what I can figure out. Any web page gurus
out there who can offer some advice?

The web page is coldwatersafety.org

I hope you managed to get the information you need to help your friend
before the thread decayed in traditional s.e.d. style. The conclusion
has to be that you use Let\'s Encrypt for a simple and entirely free
system to get a valid signed SSL certificate - it\'s what just about
everyone else does these days.

As for all the other weaknesses and attack vectors of the internet,
neither you nor anyone else can fix them - you just have to live with them.

Yes and no. I had actually found the free (for 90 days) certificate providers before this thread or at least very early on in the thread. That part is fine. But the web site still needs to be modified to work in https mode it would seem.

--

Rick C.

++ Get 1,000 miles of free Supercharging
++ Tesla referral code - https://ts.la/richard11209
 
On 03/12/2020 21:26, Rick C wrote:
On Thursday, December 3, 2020 at 1:09:42 PM UTC-5, David Brown
wrote:
On 01/12/2020 03:15, Rick C wrote:
Anyone know about SSL certificates for a web site? I\'m trying to
help a friend who had a web site for his non-profit and I don\'t
quite understand the details. The web hosting provides a
certificate which I copied to Cpanel and it says it is installed,
but opening the web page still reports a problem with security.

At this point I\'m guessing this has to do with the fact that the
certificate is not issued by an authority, but rather self
signed. I found a site that gives out 90 day free certificates
and installed one. Just typing the web site URL doesn\'t show a
safe site, but typing https: manually does, however the web site
doesn\'t work correctly. The initial page has some sort of fancy
dancy animated text that doesn\'t work and you can\'t get past
that.

I\'ve reached the limits of what I can figure out. Any web page
gurus out there who can offer some advice?

The web page is coldwatersafety.org

I hope you managed to get the information you need to help your
friend before the thread decayed in traditional s.e.d. style. The
conclusion has to be that you use Let\'s Encrypt for a simple and
entirely free system to get a valid signed SSL certificate - it\'s
what just about everyone else does these days.

As for all the other weaknesses and attack vectors of the internet,
neither you nor anyone else can fix them - you just have to live
with them.

Yes and no. I had actually found the free (for 90 days) certificate
providers before this thread or at least very early on in the thread.

Let\'s Encrypt is free without time limit. (Of course each certificate
has an expiry date, and needs regularly renewed - but that can be
automated.)

That part is fine. But the web site still needs to be modified to
work in https mode it would seem.

That should be handled easily once you have a certificate in place.
Simply avoid using \"http://\" in links, anchors, etc. As a general rule,
you shouldn\'t use absolute addresses anyway unless you really need them
- relative addresses make it easier to move the pages around, such as
between a test server and the real server.

There have been suggestions in this thread that http (port 80) should
have pages set up to redirect to https (port 443). I wouldn\'t bother -
simply drop the http port 80 altogether. (Leave it free for Let\'s
Encrypt scripts.) For normal web usage, plain http is basically dead
now, and many browsers won\'t use it without all sorts of complaints and
\"are you sure?\" boxes.
 
\"David Brown\" <david.brown@hesbynett.no> wrote in message
news:rqbip6$p64$1@dont-email.me...
On 03/12/2020 21:26, Rick C wrote:
On Thursday, December 3, 2020 at 1:09:42 PM UTC-5, David Brown
wrote:
On 01/12/2020 03:15, Rick C wrote:
Anyone know about SSL certificates for a web site? I\'m trying to
help a friend who had a web site for his non-profit and I don\'t
quite understand the details. The web hosting provides a
certificate which I copied to Cpanel and it says it is installed,
but opening the web page still reports a problem with security.

At this point I\'m guessing this has to do with the fact that the
certificate is not issued by an authority, but rather self
signed. I found a site that gives out 90 day free certificates
and installed one. Just typing the web site URL doesn\'t show a
safe site, but typing https: manually does, however the web site
doesn\'t work correctly. The initial page has some sort of fancy
dancy animated text that doesn\'t work and you can\'t get past
that.

I\'ve reached the limits of what I can figure out. Any web page
gurus out there who can offer some advice?

The web page is coldwatersafety.org

I hope you managed to get the information you need to help your
friend before the thread decayed in traditional s.e.d. style. The
conclusion has to be that you use Let\'s Encrypt for a simple and
entirely free system to get a valid signed SSL certificate - it\'s
what just about everyone else does these days.

As for all the other weaknesses and attack vectors of the internet,
neither you nor anyone else can fix them - you just have to live
with them.

Yes and no. I had actually found the free (for 90 days) certificate
providers before this thread or at least very early on in the thread.

Let\'s Encrypt is free without time limit. (Of course each certificate
has an expiry date, and needs regularly renewed - but that can be
automated.)

That part is fine. But the web site still needs to be modified to
work in https mode it would seem.


That should be handled easily once you have a certificate in place.
Simply avoid using \"http://\" in links, anchors, etc. As a general rule,
you shouldn\'t use absolute addresses anyway unless you really need them
- relative addresses make it easier to move the pages around, such as
between a test server and the real server.

There have been suggestions in this thread that http (port 80) should
have pages set up to redirect to https (port 443). I wouldn\'t bother -

I wouldn\'t either if it wasn\'t so trivially easy, at least on my setup.

simply drop the http port 80 altogether. (Leave it free for Let\'s
Encrypt scripts.)

If it has to be listening anyway then you can\'t drop it but it\'s your choice
whether or not you want a redirect to https.
With a redirect then someone trying to get to yoursite.com will
automatically end up at https://yoursite.com

For normal web usage, plain http is basically dead
now, and many browsers won\'t use it without all sorts of complaints and
\"are you sure?\" boxes.

I get no complaints from Firefox here: http://neverssl.com/
 
On 03/12/2020 22:34, Edward Rawde wrote:
\"David Brown\" <david.brown@hesbynett.no> wrote in message
news:rqbip6$p64$1@dont-email.me...
On 03/12/2020 21:26, Rick C wrote:
On Thursday, December 3, 2020 at 1:09:42 PM UTC-5, David Brown
wrote:
On 01/12/2020 03:15, Rick C wrote:
Anyone know about SSL certificates for a web site? I\'m trying to
help a friend who had a web site for his non-profit and I don\'t
quite understand the details. The web hosting provides a
certificate which I copied to Cpanel and it says it is installed,
but opening the web page still reports a problem with security.

At this point I\'m guessing this has to do with the fact that the
certificate is not issued by an authority, but rather self
signed. I found a site that gives out 90 day free certificates
and installed one. Just typing the web site URL doesn\'t show a
safe site, but typing https: manually does, however the web site
doesn\'t work correctly. The initial page has some sort of fancy
dancy animated text that doesn\'t work and you can\'t get past
that.

I\'ve reached the limits of what I can figure out. Any web page
gurus out there who can offer some advice?

The web page is coldwatersafety.org

I hope you managed to get the information you need to help your
friend before the thread decayed in traditional s.e.d. style. The
conclusion has to be that you use Let\'s Encrypt for a simple and
entirely free system to get a valid signed SSL certificate - it\'s
what just about everyone else does these days.

As for all the other weaknesses and attack vectors of the internet,
neither you nor anyone else can fix them - you just have to live
with them.

Yes and no. I had actually found the free (for 90 days) certificate
providers before this thread or at least very early on in the thread.

Let\'s Encrypt is free without time limit. (Of course each certificate
has an expiry date, and needs regularly renewed - but that can be
automated.)

That part is fine. But the web site still needs to be modified to
work in https mode it would seem.


That should be handled easily once you have a certificate in place.
Simply avoid using \"http://\" in links, anchors, etc. As a general rule,
you shouldn\'t use absolute addresses anyway unless you really need them
- relative addresses make it easier to move the pages around, such as
between a test server and the real server.

There have been suggestions in this thread that http (port 80) should
have pages set up to redirect to https (port 443). I wouldn\'t bother -

I wouldn\'t either if it wasn\'t so trivially easy, at least on my setup.

It is indeed trivially easy to do. But that doesn\'t necessarily make it
worth doing - especially as it makes one of the convenient ways of
running Let\'s Encrypt a little less easy.

simply drop the http port 80 altogether. (Leave it free for Let\'s
Encrypt scripts.)

If it has to be listening anyway then you can\'t drop it but it\'s your choice
whether or not you want a redirect to https.

What is \"it\" that is listening? You need your webserver listening on
port 443 to serve the site. For the simplest way of running the Let\'s
Encrypt scripts, you have them running on port 80 briefly for renewals
or when you want a new certificate (you can run them automatically once
a week, for example). So if you have your webserver also listening on
port 80 - despite it being useless - you then have to stop your
webserver while renewing your certificates. That\'s not hard either, of
course.

Unless you are expecting people to use seriously outdated browsers or
some other unusual methods for accessing the website, http is no longer
useful. And you don\'t even need a redirect - if someone puts http into
the address line, and the browser fails to make contact, it should try
https anyway.

With a redirect then someone trying to get to yoursite.com will
automatically end up at https://yoursite.com

For normal web usage, plain http is basically dead
now, and many browsers won\'t use it without all sorts of complaints and
\"are you sure?\" boxes.

I get no complaints from Firefox here: http://neverssl.com/

It seems I was wrong about that. I have certainly had complaints in
some cases. In fact, I have found it so inconvenient in Firefox for
some cases where I need to use http, such as for accessing web
interfaces to some firewalls, routers, switches, etc., that I generally
use Chromium for that kind of thing. Perhaps there is something else
going wrong in those cases. So thanks for the correction.
 
\"David Brown\" <david.brown@hesbynett.no> wrote in message
news:rqcv9l$5jf$1@dont-email.me...
On 03/12/2020 22:34, Edward Rawde wrote:
\"David Brown\" <david.brown@hesbynett.no> wrote in message
news:rqbip6$p64$1@dont-email.me...
On 03/12/2020 21:26, Rick C wrote:
On Thursday, December 3, 2020 at 1:09:42 PM UTC-5, David Brown
wrote:
On 01/12/2020 03:15, Rick C wrote:
Anyone know about SSL certificates for a web site? I\'m trying to
help a friend who had a web site for his non-profit and I don\'t
quite understand the details. The web hosting provides a
certificate which I copied to Cpanel and it says it is installed,
but opening the web page still reports a problem with security.

At this point I\'m guessing this has to do with the fact that the
certificate is not issued by an authority, but rather self
signed. I found a site that gives out 90 day free certificates
and installed one. Just typing the web site URL doesn\'t show a
safe site, but typing https: manually does, however the web site
doesn\'t work correctly. The initial page has some sort of fancy
dancy animated text that doesn\'t work and you can\'t get past
that.

I\'ve reached the limits of what I can figure out. Any web page
gurus out there who can offer some advice?

The web page is coldwatersafety.org

I hope you managed to get the information you need to help your
friend before the thread decayed in traditional s.e.d. style. The
conclusion has to be that you use Let\'s Encrypt for a simple and
entirely free system to get a valid signed SSL certificate - it\'s
what just about everyone else does these days.

As for all the other weaknesses and attack vectors of the internet,
neither you nor anyone else can fix them - you just have to live
with them.

Yes and no. I had actually found the free (for 90 days) certificate
providers before this thread or at least very early on in the thread.

Let\'s Encrypt is free without time limit. (Of course each certificate
has an expiry date, and needs regularly renewed - but that can be
automated.)

That part is fine. But the web site still needs to be modified to
work in https mode it would seem.


That should be handled easily once you have a certificate in place.
Simply avoid using \"http://\" in links, anchors, etc. As a general rule,
you shouldn\'t use absolute addresses anyway unless you really need them
- relative addresses make it easier to move the pages around, such as
between a test server and the real server.

There have been suggestions in this thread that http (port 80) should
have pages set up to redirect to https (port 443). I wouldn\'t bother -

I wouldn\'t either if it wasn\'t so trivially easy, at least on my setup.

It is indeed trivially easy to do. But that doesn\'t necessarily make it
worth doing - especially as it makes one of the convenient ways of
running Let\'s Encrypt a little less easy.


simply drop the http port 80 altogether. (Leave it free for Let\'s
Encrypt scripts.)

If it has to be listening anyway then you can\'t drop it but it\'s your
choice
whether or not you want a redirect to https.

What is \"it\" that is listening?

Nginx in my case. On 80, 443 and at least two others.
Yes there\'s a restart when the certificate renews but I never notice.
If the server is listening on 443 then in my view it may as well be
listening on 80.
After all it\'s the same server (in my case).
But I don\'t see any point arguing over this because I rarely see two
Internet connected systems set up the same.
Much of it depends on personal preference.

You need your webserver listening on
port 443 to serve the site. For the simplest way of running the Let\'s
Encrypt scripts, you have them running on port 80 briefly for renewals
or when you want a new certificate (you can run them automatically once
a week, for example). So if you have your webserver also listening on
port 80 - despite it being useless - you then have to stop your
webserver while renewing your certificates. That\'s not hard either, of
course.

Unless you are expecting people to use seriously outdated browsers or
some other unusual methods for accessing the website, http is no longer
useful. And you don\'t even need a redirect - if someone puts http into
the address line, and the browser fails to make contact, it should try
https anyway.

With a redirect then someone trying to get to yoursite.com will
automatically end up at https://yoursite.com

For normal web usage, plain http is basically dead
now, and many browsers won\'t use it without all sorts of complaints and
\"are you sure?\" boxes.

I get no complaints from Firefox here: http://neverssl.com/


It seems I was wrong about that. I have certainly had complaints in
some cases. In fact, I have found it so inconvenient in Firefox for
some cases where I need to use http, such as for accessing web
interfaces to some firewalls, routers, switches, etc., that I generally
use Chromium for that kind of thing. Perhaps there is something else
going wrong in those cases. So thanks for the correction.
 
Rick C wrote:

But the web site still needs to be modified to work in
https mode it would seem.
OH, of COURSE! Most web browsers now REQUIRE an https connection, and will
either just go blank, or give a scary-sounding warning if it doesn\'t connect
via https.

Jon
 
On 3/12/20 7:14 am, David Brown wrote:
On 02/12/2020 20:22, Martin Brown wrote:
On 02/12/2020 15:00, David Brown wrote:
On 02/12/2020 15:12, Martin Brown wrote:
SSL certificates do not magically make the internet a safe place.  But
they do solve one part of the problem, reasonably simply and efficiently.

They ensure that no-one can interpret the data exchanged between a
browser and an encrypted platform (GCHQ/NSA possibly excluded).

They tell you that the end-point of the encrypted transfer is controlled
by the same computer or people that control the domain name.

No. They verify that the computer contains the private key matching the
certificate which was issued to the people who controlled that domain
name *at the time of issuance*.

Read the Certification Practice Statement attached to any bank\'s
certificate. You\'ll find that it requires the bank to vet IT staff and
security constantly and carefully, and many other things - these
documents are typically hundreds of pages of dense legalese.

The CA takes an active role in verifying that the bank complies with the
requires of this extended verification, and that\'s why these
certificates cost a lot more than a Letsencrypt certificate.

Also, if any one of the hundreds of trusted root CA certificates
installed in your browser is controlled by a bad actor who can MITM your
network (as happens in almost every enterprise, for example) then all
bets are off. You make a request for www.bigbank.com, and they instantly
fabricate a certificate (or serve up one they made earlier) that looks
entirely genuine (except for being signed by them, not whoever
bigbank.com bought their real certificate from. Then they decrypt your
data and forward the request to the original server, and you are none
the wiser. As I said, this is commonplace in enterprise networks,
because it\'s integral to their snooping and malware prevention strategies.

FWIW, the very first open source CA server was created and published by
yours truly, as a set of CGI scripts. But I haven\'t worked in this space
for many years now.

Clifford Heath.
 
On 3/12/20 9:28 am, Clifford Heath wrote:
On 3/12/20 7:14 am, David Brown wrote:
On 02/12/2020 20:22, Martin Brown wrote:
On 02/12/2020 15:00, David Brown wrote:
On 02/12/2020 15:12, Martin Brown wrote:
SSL certificates do not magically make the internet a safe place.  But
they do solve one part of the problem, reasonably simply and
efficiently.

They ensure that no-one can interpret the data exchanged between a
browser and an encrypted platform (GCHQ/NSA possibly excluded).

They tell you that the end-point of the encrypted transfer is controlled
by the same computer or people that control the domain name.

No. They verify that the computer contains the private key matching the
certificate which was issued to the people who controlled that domain
name *at the time of issuance*.

Read the Certification Practice Statement attached to any bank\'s
certificate.

Here\'s the CPS from the CA who issued my bank\'s certificate. Just scan
the table of contents to see what kinds of requirements it encompasses.

<https://www.digicert.com/wp-content/uploads/2020/10/DigiCert-CPS-V.5.4.1.pdf>

CH
 
On 02/12/2020 23:28, Clifford Heath wrote:
On 3/12/20 7:14 am, David Brown wrote:
On 02/12/2020 20:22, Martin Brown wrote:
On 02/12/2020 15:00, David Brown wrote:
On 02/12/2020 15:12, Martin Brown wrote:
SSL certificates do not magically make the internet a safe place.  But
they do solve one part of the problem, reasonably simply and
efficiently.

They ensure that no-one can interpret the data exchanged between a
browser and an encrypted platform (GCHQ/NSA possibly excluded).

They tell you that the end-point of the encrypted transfer is controlled
by the same computer or people that control the domain name.

No. They verify that the computer contains the private key matching the
certificate which was issued to the people who controlled that domain
name *at the time of issuance*.

Fair enough - that emphasised disclaimer is important.

Read the Certification Practice Statement attached to any bank\'s
certificate. You\'ll find that it requires the bank to vet IT staff and
security constantly and carefully, and many other things - these
documents are typically hundreds of pages of dense legalese.

I don\'t believe /anyone/ - not even the lawyers that wrote it - actually
read these hundreds of pages of legalese! But I don\'t need to read them
to agree that they probably contain the requirements you mention.

The CA takes an active role in verifying that the bank complies with the
requires of this extended verification, and that\'s why these
certificates cost a lot more than a Letsencrypt certificate.

Yes, exactly. (That is just expanding on what I have already mentioned.)

Also, if any one of the hundreds of trusted root CA certificates
installed in your browser is controlled by a bad actor who can MITM your
network (as happens in almost every enterprise, for example) then all
bets are off. You make a request for www.bigbank.com, and they instantly
fabricate a certificate (or serve up one they made earlier) that looks
entirely genuine (except for being signed by them, not whoever
bigbank.com bought their real certificate from. Then they decrypt your
data and forward the request to the original server, and you are none
the wiser. As I said, this is commonplace in enterprise networks,
because it\'s integral to their snooping and malware prevention strategies.

It all hinges on the secret keys being kept secret by trustworthy
parties. But you already need to put a lot of trust in your bank!

FWIW, the very first open source CA server was created and published by
yours truly, as a set of CGI scripts. But I haven\'t worked in this space
for many years now.

Clifford Heath.
 
On 02/12/2020 20:14, David Brown wrote:
On 02/12/2020 20:22, Martin Brown wrote:
On 02/12/2020 15:00, David Brown wrote:
On 02/12/2020 15:12, Martin Brown wrote:

SSL certificates do not magically make the internet a safe place.  But
they do solve one part of the problem, reasonably simply and efficiently.

They ensure that no-one can interpret the data exchanged between a
browser and an encrypted platform (GCHQ/NSA possibly excluded).

They tell you that the end-point of the encrypted transfer is controlled
by the same computer or people that control the domain name. Assuming
that neither your computer nor the server has been compromised in some
other way, the data exchanged cannot be read, changed or replaced, and
it is going to the right place. (That\'s a stronger than merely saying
it can\'t be viewed.)

You really only know that the other end has (access to) a private key
for the public key that you are using to communicate with it.
But of course it doesn\'t tell you that the address you think you are
using is the correct one, or that the target server hasn\'t been taken
over by hackers, or that there is no security bug in your browser, or
that the certificate signing keys have not been stolen. As an internet
user, you need to apply the level of paranoia you think appropriate.

Perhaps but I note for example that for example the domain

https://www.11oydsbank.com

Is still available. Typo lookalikes are dangerous although you might
have to register it somewhere unfussy about what they will accept.

I had a friend who got quite badly stung by a typosquatting website on a
well known commonly visited booking site once. The stupid little green
padlock was there so he thought it was all OK.

--
Regards,
Martin Brown
 
On 3/12/20 6:44 pm, David Brown wrote:
On 02/12/2020 23:28, Clifford Heath wrote:
Also, if any one of the hundreds of trusted root CA certificates
installed in your browser is controlled by a bad actor who can MITM your
network (as happens in almost every enterprise, for example) then all
bets are off. You make a request for www.bigbank.com, and they instantly
fabricate a certificate (or serve up one they made earlier) that looks
entirely genuine (except for being signed by them, not whoever
bigbank.com bought their real certificate from. Then they decrypt your
data and forward the request to the original server, and you are none
the wiser. As I said, this is commonplace in enterprise networks,
because it\'s integral to their snooping and malware prevention strategies.


It all hinges on the secret keys being kept secret by trustworthy
parties. But you already need to put a lot of trust in your bank!

No, this part doesn\'t. An enterprise can control your DNS (so when you
go to mybank.com you really don\'t) or they can MITM the connection on a
gateway even if they serve the real IP addresses.

So you get a TCP connection to an enterprise gateway, and it sees that
you want to talk SSL, so they fabricate (and sign) a certificate that
says it is from mybank.com. It\'s signed by a CA you trust (the one they
installed in your enterprise laptop or phone), and everything looks
rosy. Then they forward the traffic to mybank.com through another SSL
connection, and neither party is any the wiser. Meantime they can record
all your traffic in plain text.

Once you trust any root certificate, the owners of the matching private
key can prove *anything* to you... unless you happen to open the
certificate and discover that it isn\'t signed by the CA they actually
use, but by the bogus one.

Clifford Heath.
 
On Thursday, 3 December 2020 at 12:34:02 UTC, Clifford Heath wrote:
On 3/12/20 6:44 pm, David Brown wrote:
On 02/12/2020 23:28, Clifford Heath wrote:
Also, if any one of the hundreds of trusted root CA certificates
installed in your browser is controlled by a bad actor who can MITM your
network (as happens in almost every enterprise, for example) then all
bets are off. You make a request for www.bigbank.com, and they instantly
fabricate a certificate (or serve up one they made earlier) that looks
entirely genuine (except for being signed by them, not whoever
bigbank.com bought their real certificate from. Then they decrypt your
data and forward the request to the original server, and you are none
the wiser. As I said, this is commonplace in enterprise networks,
because it\'s integral to their snooping and malware prevention strategies.


It all hinges on the secret keys being kept secret by trustworthy
parties. But you already need to put a lot of trust in your bank!
No, this part doesn\'t. An enterprise can control your DNS (so when you
go to mybank.com you really don\'t) or they can MITM the connection on a
gateway even if they serve the real IP addresses.

So you get a TCP connection to an enterprise gateway, and it sees that
you want to talk SSL, so they fabricate (and sign) a certificate that
says it is from mybank.com. It\'s signed by a CA you trust (the one they
installed in your enterprise laptop or phone), and everything looks
rosy. Then they forward the traffic to mybank.com through another SSL
connection, and neither party is any the wiser. Meantime they can record
all your traffic in plain text.

Once you trust any root certificate, the owners of the matching private
key can prove *anything* to you... unless you happen to open the
certificate and discover that it isn\'t signed by the CA they actually
use, but by the bogus one.

Clifford Heath.

A lot of schools also do this. Every computer which is used on the school network
has a special certificate installed which allows their proxy server to intercept
https connections and report on anything \"inappropriate\".
I have often wondered where the liability would lie if a banking scam caused
significant losses to a teacher using the school network for internet banking.

John
 

Welcome to EDABoard.com

Sponsor

Back
Top