Skip to main content ↑ ↓
Topic: Cannot access Artix' sources/PKGBUILDs: gitea.[...] / packages.artixlinux.org (Read 1749 times) previous topic - next topic
0 Members and 8 Guests are viewing this topic.

Re: Cannot access Artix' sources/PKGBUILDs: gitea.[...] / packages.artixlinux.org

Reply #15 –
 
Yep @gripped said it right, a VPN encrypts traffic between your pc and the remote VPN server. Then the VPN server connects to the needed website fetches the data and encrypts it inside it's payload (with the header and payload) then it sends it back to you with a new packet header specific to that VPN server used. So all handshakes are negotiated at the remote VPN server and if that is improper configured some connections may fail.

Re: Cannot access Artix' sources/PKGBUILDs: gitea.[...] / packages.artixlinux.org

Reply #16 –
Quote from: Surf3r – on
You can check your client which in case you use VPN your client is your VPN server in use. TEST HERE

Result: TLS 1.0 up to TLS 1.3 is available. See attached screenshot for full details.




Quote from: gripped – on
It doesn't hijack the SSL connection. It makes the SSL connection.

If the VPN server makes the VPN connection, then it is like hijacking: I want to make a SSL connection from my browser to the target server. End-to-end encryption between my browser and the target server. If some intermediate (like the VPN server) makes the SSL connection, then it is not anymore end-to-end encryption between my browser and the target server.


You confuse a VPN with a proxy:

The VPN encapsulates the traffic between my computer and the VPN providers data center. My computer makes the direct connection to gitea.artixlinux.com, but on the way it is routed through a special tunnel where it _additionally_ is encapsulated at the one side and decapsulated at the other side. That does not interfer with the connection that my browser makes to the target website. (A web proxy would do that.) This is like any other path my data might take through the internet, different routers, the internet service provider, etc. The VPN simply make me come "into the internet" at a different point (from a different IP adress) than if I would go directly through the internet service provider. That's the purpose of a tunnel: To just encapsulate what flows through it, not doing stuff on behalf of any site.
 

Re: Cannot access Artix' sources/PKGBUILDs: gitea.[...] / packages.artixlinux.org

Reply #17 –

 Nope you didn't get it right. Visit this link while you have your VPN on, write down the ip then visit again that page with the VPN turned off and you'll see a different ip. If things would be like you say it would mean in both cases you should get the same ip which isn't the case not on a VPN nor on a proxy.

You have to test your client with the VPN server that gave that error not with the other that works. Also i can't see any print screen you speak of.

Any website you visit thru a VPN it will see public ip of the VPN server not yours. It's like you send a box and your VPN provider put your box inside a bigger box with its ip on it, the WEBSITE negotiate based on that bigger box (not based on your smaller box from your ff) cos it doesn't know inside there's another box (with your real ip) puts that requested info inside that bigger box goes back to VPN server that sends it back to you and your firewall checks bigger box header then pass it on to your VPN client that's the only app that can figure out what's inside (except the VPN server)

If you don't understand the technology you need to take a closer look.

The difference between a proxy and a VPN is that the PROXY does not hide metadata between you and the proxy (on the wire) so only the website will don't know your real ip while VPN hides metadata inside its payload and nobody including those that can sniff data on the wire have no idea what website you're on. (except the guys that run the VPN server)

 A VPN doesn't turn you into a 100% anonymous guy, it only keeps data private against 3rd parties.

Re: Cannot access Artix' sources/PKGBUILDs: gitea.[...] / packages.artixlinux.org

Reply #18 –
Quote from: Surf3r – on
Nope you didn't get it right. Visit this link while you have your VPN on, write down the ip then visit again that page with the VPN turned off and you'll see a different ip. If things would be like you say it would mean in both cases you should get the same ip which isn't the case not on a VPN nor on a proxy.

Of course I get a different IP with a VPN. That is what I meant with "The VPN simply make me come "into the internet" at a different point (from a different IP adress)".

Quote from: Surf3r – on
You have to test your client with the VPN server that gave that error

Yes, I did exactly that!

To verify, I tried to visit https://gitea.artixlinux.org/ before and after the ssllabs-test and confirmed that I get the connection error.

Quote from: Surf3r – on
Also i can't see any print screen you speak of.

Here again:

https://i.imgur.com/sIvMZTe.png

.. it was embedded in the previous post as
Code: [Select]
[img width=120]https://i.imgur.com/sIvMZTe.png[/img]


Quote from: Surf3r – on
Any website you visit thru a VPN it will see public ip of the VPN server not yours. It's like you send a box and your VPN provider put your box inside a bigger box with its ip on it,

that is exactly what it is supposed to do.

Quote from: Surf3r – on
the WEBSITE negotiate based on that bigger box (not based on your smaller box from your ff) cos it doesn't know inside there's another box

No. The website negotiates directly with my browser. That is the idea of the "boxes": they just encapsulate and de-capsulate the traffic. To the website, it looks that my browser comes from the IP of the VPN server, but it is my browser which makes the negotiation.

OpenVPN (which is the standard I use) operates at OSI layer 2 or 3. This is at most at the network level (where also IP is), and below the "Transport"-Level (TCP ...) and the "Session"-level (HTTPS ...). (-> Wikipedia "OSI model".)

The layers are such that lower level layers are transparent with regard to higher level.

Quote from: Surf3r – on
(with your real ip)

What do you mean with "real IP"? Locally I have 192.168.100.4. Then this gets to my router. On the output, it has some 10.x-IP to my internet service provider. The internet service provider exits to the internet at again a different IP.

You need to define what you mean with "real IP", because even without a VPN there are layers of routing and tunneling (in my case, via mobile network) involved.

Quote from: Surf3r – on
A VPN doesn't turn you into a 100% anonymous guy,

For sure!

And not every VPN is for beeing anonymous. VPNs can be used to virtually connect networks, or to appear to the internet from a different IP, to provide a real network over some poor man's tunnel (like tunneling network via DNS), ...

Re: Cannot access Artix' sources/PKGBUILDs: gitea.[...] / packages.artixlinux.org

Reply #19 –
 Your real ip is your public ip that you get from the ISP.

If the handshake would be made in your browser the website would know your real public ip. So because the WEBSITE have no idea at least that's intended (VPN has to have no leaks which some do have) it starts negotiate handshake with the VPN ip (bigger box). The VPN has to be configured in such a way to let WEBSITE know what he needs of course based on what your browser can do but without exposing anything more than needed.

Also is wrong to say handshake happens in your browser cos it's rather a dialog. Your VPN advertise protocols your client supports (firefox), and the WEBSITE tells your VPN what it needs to start exchanging data. The handshake is successful when both parties receives the ok and starts normal operation.

When the WEBSITE sends the ok it sends it to the VPN server ip then the VPN forwards it to your public ip but its payload is encrypted. After that it reaches your router and then your VPN client on your pc

Re: Cannot access Artix' sources/PKGBUILDs: gitea.[...] / packages.artixlinux.org

Reply #20 –
Quote from: Surf3r – on
Your real ip is your public ip that you get from the ISP.

OK, let's take that as definition (I also can have several parallel connections to the internet at the same time, by the way).

Quote from: Surf3r – on
If the handshake would be made in your browser the website would know your real public ip.

You confuse the different network layers.

Quote from: Surf3r – on
So because the WEBSITE have no idea at least that's intended (VPN has to have no leaks which some do have) it starts negotiate handshake with the VPN ip (bigger box). The VPN has to be configured in such a way to let WEBSITE know what he needs of course based on what your browser can do but without exposing anything more than needed.

That would imply that the VPN would not be a network transparent to higher OSI layers, but would need to intercept all of them. Especially, it would imply that only a defined set of application protocols can be supported.



Quote from: Surf3r – on
When the WEBSITE sends the ok it sends it to the VPN server ip then the VPN forwards it to your public ip but its payload is encrypted. After that it reaches your router and then your VPN client on your pc

Given your explanation, each router on the way would also need to make the handshake


Let me try with an analogy to ordinary mail:

Assume I want to write a letter to my city council to inquire some information.

The direct way would be to write the letter with my request on it, but it in an envelope, put the address of the city council on the envelope.

Then I go to the mail box and shortly before putting it into the mail box I write my address on the "sender" field of the envelope, so that the answer can be returned to me.

Then I put the envelope with the letter inside into the mail box. 

The mail company will find the letter in it's mail box, and will deliver it to the address stated on the envelope. 
The letter arrives at the city council, they open the envelope, and find my letter. They keep the envelope to remember the sender address, then they process my inquiry, and then they send back the answer to the address given as "sender" on the envelope.

So I will receive the answer.



Now, I also can do the following:

I can put above envelope, with the address of the city council on it, into another envelope which has the address of my employer on it. Shortly before putting this into the mail box I write my address as the "sender" address on the outer envelope.

Then the mail company will deliver the letter to my employer, not to the city council.

My employer will open the outer envelope, and they discover that there is an inner envelope inside. They will write their address in the "sender" field of the inner envelope and put the inner envelope into the mail box.

Then the inner envelope will be delivered to the city council.

They open the inner envelope and find my request.

Now, the answers also flow back via my employer to me (as the "sender" addresses on the envelopes stated). But the letter itself is still the same.



In this analogy, the mail companiees are the internet service provider(s), my employer is the VPN. The letter is the request that my web browser does, i.e. SSL/TLS handshakes. The addresses are IP addresses.

---

In this analogy, a proxy would be when I would not use an outer envelope but would mail the letter directly to my employer, which would read the letter, rewrite it on their own paper, and then send it to the city council.

Re: Cannot access Artix' sources/PKGBUILDs: gitea.[...] / packages.artixlinux.org

Reply #21 –
Quote from: dreieck – on
META: I don't know why this post gets malformatted every time, the forum inserts a "code"-tagat the very beginning, every time I edit the post and remove it it get's re-inserted.

In the Web Browser (Firefox):

FWIW - it works with firefox, but firefox is not in anyway a perfect thing.  It sounds like network connectivity?

Re: Cannot access Artix' sources/PKGBUILDs: gitea.[...] / packages.artixlinux.org

Reply #22 –
The best you can do is fire up wireshark and see what goes where and why.

Those routers have the purpose to forward packets not make handshakes. Routers don't have openssl unless they have VPN function and allocated a public ip, which they not have. Also handshakes doesn't happen between internal ip unless it's different kind of network and also because the packet recipient is your pc public ip an not the router's internal ip (unless someone tries a man in the middle attack)

> You confuse the different network layers.
No there's only 1, network layer (OSI has 7 layers)

You need your real ip to reach VPN server that creates the TUNNEL between you and VPN server. It's improper to use the term TUNNEL though as what in fact is it's a packet sent via public ip the only thing is that the payload is encrypted and contains everything VPN negotiated/fetched from the WEBSITE on your behalf

VPN server negotiate on your behalf (like it's you and you are like him) based on what you send of course, obfuscating your real ip and other metadata (like time etc) that would de-anonymize you .

I'm gonna try draw a detailed scheme so it will be much easy to visualize 100% what happens.

Re: Cannot access Artix' sources/PKGBUILDs: gitea.[...] / packages.artixlinux.org

Reply #23 –
Quote from: Surf3r – on
your pc public ip

My PC has just the IP 192.168.100.4.

My router makes NAT to some 10.x.x.x (which is the network of my internet service provider), which then has a public IP (probably
shared  with some other internet users, the ISPs NAT keeps track of what  incoming has to go where).

Another PC at home has 192.168.100.2, and  goes to the internet via the same router, via the same 10.x.x.x, and then at the ISP site via the same public IP.

The router also is a  computer (I even have a text browser on it which can be used via ssh), and when the router accesses the internet it has the same public IP.

There is no clear notion of "my PC public IP", because all my devices including the router share the same public IP to the outside world, as given by the ISP.


VPN steps  in at the 10.x.x.x-part and adds another IP to the router, which is like 10.y.y.y, in the network of the VPN server. The VPN server has a public IP, which is different from the one of my ISP. Physically, the packets via the VPN server travel via the ISP

---

Someone suggested that PMTUD might be broken, I have to research what this is.

Quote from: Surf3r – on
I'm gonna try draw a detailed scheme so it will be much easy to visualize 100% what happens.

Yes, please.

Re: Cannot access Artix' sources/PKGBUILDs: gitea.[...] / packages.artixlinux.org

Reply #24 –
Quote from: dreieck – on
Someone suggested that PMTUD might be broken, ...

lol

https://en.wikipedia.org/wiki/Path_MTU_Discovery
"Wer alles kann, macht nichts richtig"

Artix USE="runit openrc slim openbox lxde gtk2 qt4 qt5 qt6 conky
-gtk3 -gtk4 -adwaita{cursors,themes,icons} -gnome3 -kde -plasma -wayland "