https question

Hi,

https should ensure a secure connection beyween my pc and a server.

But I am also connected to my ISP.

Could the ISP read data sent to a server via https?

Thanks

not_here.5.species8350@xoxy.net <not_here.5.species8350@xoxy.net> wrote:
> https should ensure a secure connection beyween my pc and a server.
> But I am also connected to my ISP.
> Could the ISP read data sent to a server via https?

If you're doing right, then HTTPS is implementing endpoint-to-endpoint
encryption, so the answer is: no, they can't.

Yours,
VB.
--
Nur im Staat Tuvalu gibt es weniger Katholiken als im Vatikan.

(Wikipedia)

not_here.5.species8350@xoxy.net wrote:
> Hi,
>
> https should ensure a secure connection beyween my pc and a server.
>
> But I am also connected to my ISP.
>
> Could the ISP read data sent to a server via https?

Not unless they have tampered with the browser that you are using, or
you failed to check that the SSL certificate being used for the session,
or at the least the URL you are actually using, actually belongs to the
organisation that you are communicating with. (The biggest flaw in SSL
is that most people do not check this, and even fewer check that the
root certificate used offers an adequate level of authentication for the
use to which it is being put.)

This makes the, reasonable, assumption that your ISP is not one of the
official root certificate providers for your browser, and, of course,
that they are unconnected with the site you are using.

"not_here.5.species8350@xoxy.net" <not_here.5.species8350@xoxy.net>
writes:
> https should ensure a secure connection beyween my pc and a server.
>
> But I am also connected to my ISP.
>
> Could the ISP read data sent to a server via https?

not unless the ISP is running the server. HTTPS provides for
authenticating the (remote) server and then establishing an encrypted,
end-to-end "session" between the client and the server (only the
end-points see the unencrypted information, all others just see a lot of
encrypted noise).

we had been called in to consult with small client/server startup that
wanted to do payment transactions on their server and had also invented
this technology called SSL (or sometimes HTTPS) they wanted to use.
They also wanted to use it between the server and something called the
"payment gateway" ... lots of past posts mentioning deployment of
"payment gateway":
http://www.garlic.com/~lynn/subnetwork.html#gateway

part of the gateway deployment was some number of compensating processes
that further increased the integrity/assurance of the server/gateway
communication.

there was also detailed end-to-end audit of all the processes related to
SSL/HTTPS, including walk-thrus of several of these new operations
calling themselves certification authorities that were issuing these
things referred to as SSL domain name digital certificates ... some
number of past posts
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

part of the assumption for correct client/server HTTPS operation was
that the end-user understood the relationship between the server that
the client thought they were talking to and the (HTTPS) URL used by the
browser. The end-user types in the URL (for the known server), and the
browser then uses SSL/HTTPS to validate the relationship between the URL
and the server that it is talking to. This creates the trust chain that
the server the end-user believes they are talking to is actually, the
server they are talking to (but a critical component is the end-user
understand the relationship between the server they think they are
talking to and that server's URL).

for electronic commerce, almost immediately the merchant servers
discovered that SSL cut their thruput by 90%-95% ... and as a result
they dropped back to just using SSL for check-out/payment.

Now the URL provided by the end-user is no longer validated by the
browser (since SSL is no longer being used). The (unvalidated) merchant
site then provides a button to click ... which provides the URL. This
invalides original assumption about SSL integrity ... since the URL
provided by the end-user isn't being validated ... and the URL that is
being validated is provided by an (unvalidated) website (not by the
end-user).

This "click" convention has created a disconnect for end-users
.... between the server they think they are talking to and the
corresponding URL for that server (an original integrity assumption for
SSL, required that the end-user understand/know the relationship between
the server they think they are talking to and the URL for that server).

For a man-in-the-middle attack ... lots of past posts
http://www.garlic.com/~lynn/subintegrity.html#mitm

An unvalidated source ... provides a field asking the end-user to
click. This field supplies a URL that takes the browser to a server
.... that may actually have a valid digital certificate for that
server. The (potentially bogus) server (with a valid digital
certificate), then has a valid SSL session, connected to the
client. This server can run a slightly modified version of some "proxy
software" ... which transparently creates another SSL connection with
another server (the server that the user actually believes they are
talking to) ... and forwards everything between the two sessions (while
evesdropping on all the communication).

Another kind of attack, is a client end-point attack ... where the
client downloads some sort of applet, virus, and/or trojan ... that
compromises the PC and views all the unencrypted input/output ... before
the browser does the SSL part. This applet/virus/trojan then users a
different session with a 3rd party, providing a copy of all unencrypted
information.

--
40+yrs virtualization experience (since Jan68), online at home since Mar70