info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
debian in der VM, HTTP_PROXY, auch via Host System und viele Fragen hierzu
5 views
Skip to first unread message
Florian (flobee)
Jan 12, 2024, 4:30:04 PMJan 12
to
Hallo Liste
Vorab: Netzwerk ist nicht meins.
In der Firma wurden http proxy Einstellungen gesetzt, um in die Welt
zu kommen und ganz besonders z.b bei Nutzung von git, curl oder sogar
wget muss etwas gemacht werden. Und der Firefox will auch speziell
behandelt/eingestellt werden. Host System ist WinTendo und dort gibt
es HTTP[S]_PROXY environment Variablen:
HTTP_PROXY=http://USER@HOST:PORT und das **gleiche** für HTTPS (beides
'http' ohne S) [1].
Via Virtualbox habe ich ein Debian 12 (VM mit Netzwerkbrücke). Ich
bekomme eine IP, resolv.conf auf das Netzwerk angepasst (nameserver
x.x.x.x, search host1 host2..) , und ssh IP_TO_VM vom Host System zur
VM (via Win Git Bash) funktioniert ohne weitere Einstellungen.
Wie ich herausfand, gibt es keine zentrale Einstellung in einem
debian/ Linux System für derartige Einstellungen. Genau genommen
LinTendo da es bei Windows scheinbar nur diese einmalige Einstellung
gibt, um http nach draußen via PROXY zu definieren.
`/etc/enviroment`, `/etc/profile.d/*[proxy.sh], bashrc (allgm. shell
rc files), Browser, git und und und. Try & Error
Nur sehr wenige Provider bieten sogar Standard http ports 80, 8080,
443 für spezielle Dienste, die eigentlich per default irgendwo > Port
1024 sind.
Mit anderen Worten: Auch die Ports nach draußen scheinen reduziert.
ssh geht schon mal null und nicht. Vermutlich aber via 443, wie ich an
anderer Stelle herausfand. Können viele Provider/Dienste aber nicht.
Meine Fragen:
- [1] Ist das http für https anfragen via proxy Sicher? Oder kann die
IT mitlesen? 'Man in the middle'?
- Mit der debian VM komme ich auf klassischen Port raus.
Kann ich die Welt für mich irgendwie deutlich verbessern und was
muss ich tun?
Z.b ssh zu gitlab, github mit public key auth wäre schon cool
VG
Vorab: Netzwerk ist nicht meins.
In der Firma wurden http proxy Einstellungen gesetzt, um in die Welt
zu kommen und ganz besonders z.b bei Nutzung von git, curl oder sogar
wget muss etwas gemacht werden. Und der Firefox will auch speziell
behandelt/eingestellt werden. Host System ist WinTendo und dort gibt
es HTTP[S]_PROXY environment Variablen:
HTTP_PROXY=http://USER@HOST:PORT und das **gleiche** für HTTPS (beides
'http' ohne S) [1].
Via Virtualbox habe ich ein Debian 12 (VM mit Netzwerkbrücke). Ich
bekomme eine IP, resolv.conf auf das Netzwerk angepasst (nameserver
x.x.x.x, search host1 host2..) , und ssh IP_TO_VM vom Host System zur
VM (via Win Git Bash) funktioniert ohne weitere Einstellungen.
Wie ich herausfand, gibt es keine zentrale Einstellung in einem
debian/ Linux System für derartige Einstellungen. Genau genommen
LinTendo da es bei Windows scheinbar nur diese einmalige Einstellung
gibt, um http nach draußen via PROXY zu definieren.
`/etc/enviroment`, `/etc/profile.d/*[proxy.sh], bashrc (allgm. shell
rc files), Browser, git und und und. Try & Error
Nur sehr wenige Provider bieten sogar Standard http ports 80, 8080,
443 für spezielle Dienste, die eigentlich per default irgendwo > Port
1024 sind.
Mit anderen Worten: Auch die Ports nach draußen scheinen reduziert.
ssh geht schon mal null und nicht. Vermutlich aber via 443, wie ich an
anderer Stelle herausfand. Können viele Provider/Dienste aber nicht.
Meine Fragen:
- [1] Ist das http für https anfragen via proxy Sicher? Oder kann die
IT mitlesen? 'Man in the middle'?
- Mit der debian VM komme ich auf klassischen Port raus.
Kann ich die Welt für mich irgendwie deutlich verbessern und was
muss ich tun?
Z.b ssh zu gitlab, github mit public key auth wäre schon cool
VG
Ulf Volmer
Jan 12, 2024, 4:50:04 PMJan 12
to
Am 12.01.24 um 22:28 schrieb Florian (flobee):
> - [1] Ist das http für https anfragen via proxy Sicher? Oder kann die
> IT mitlesen? 'Man in the middle'?
Die 'IT' in Form des Proxy Betreibers kann sowieso mitlesen.
Relevant ist hier die Verbindung zum Ziel:
http: Proxy Betreiber kann mitlesen
https: der Proxy verwendet die Direkt- Verbindung zum Ziel, der
Betreiber kann üblicherweise nicht mitlesen. Ausnahme ist hier, wenn der
Prxy die TLS Verbindung aufbricht, dann kann er auch wieder mitlesen.
Dazu braucht es aber ein auf dem Client installiertes CA Zertifikat,
damit das keine Fehler wirft.
Die Entscheidung, für die Verbindung **zum** Proxy https zu verwenden,
verhindert hier nur MitM innerhalb des Firemnetzes.
> - Mit der debian VM komme ich auf klassischen Port raus.
> Kann ich die Welt für mich irgendwie deutlich verbessern und was
> muss ich tun?
> Z.b ssh zu gitlab, github mit public key auth wäre schon cool
Wenn Deine Firma entschieden hat, ausgehende ssh Verbindungen zu
blockieren, wird sie sich vermutlich etwas dabei gedacht haben.
Die Optionen, sowas zu umgehen, könnten das Arbeitsverhältnis vermutlich
beschleunigt terminieren.
Aber fragen kann man ja. Dien genannte gitlab Verbindug läßt sich ja
verargumentieren.
Viele Grüße
Ulf
> - [1] Ist das http für https anfragen via proxy Sicher? Oder kann die
> IT mitlesen? 'Man in the middle'?
Relevant ist hier die Verbindung zum Ziel:
http: Proxy Betreiber kann mitlesen
https: der Proxy verwendet die Direkt- Verbindung zum Ziel, der
Betreiber kann üblicherweise nicht mitlesen. Ausnahme ist hier, wenn der
Prxy die TLS Verbindung aufbricht, dann kann er auch wieder mitlesen.
Dazu braucht es aber ein auf dem Client installiertes CA Zertifikat,
damit das keine Fehler wirft.
Die Entscheidung, für die Verbindung **zum** Proxy https zu verwenden,
verhindert hier nur MitM innerhalb des Firemnetzes.
> - Mit der debian VM komme ich auf klassischen Port raus.
> Kann ich die Welt für mich irgendwie deutlich verbessern und was
> muss ich tun?
> Z.b ssh zu gitlab, github mit public key auth wäre schon cool
blockieren, wird sie sich vermutlich etwas dabei gedacht haben.
Die Optionen, sowas zu umgehen, könnten das Arbeitsverhältnis vermutlich
beschleunigt terminieren.
Aber fragen kann man ja. Dien genannte gitlab Verbindug läßt sich ja
verargumentieren.
Viele Grüße
Ulf
Florian (flobee)
Jan 12, 2024, 5:40:04 PMJan 12
to
Hi
Danke für Antwort!
Am Fr., 12. Jan. 2024 um 22:46 Uhr schrieb Ulf Volmer <u.vo...@u-v.de>:
>
> Am 12.01.24 um 22:28 schrieb Florian (flobee):
>
> > - [1] Ist das http für https anfragen via proxy Sicher? Oder kann die
> > IT mitlesen? 'Man in the middle'?
>
> Die 'IT' in Form des Proxy Betreibers kann sowieso mitlesen.
> Relevant ist hier die Verbindung zum Ziel:
>
> http: Proxy Betreiber kann mitlesen
> https: der Proxy verwendet die Direkt- Verbindung zum Ziel, der
> Betreiber kann üblicherweise nicht mitlesen. Ausnahme ist hier, wenn der
> Prxy die TLS Verbindung aufbricht, dann kann er auch wieder mitlesen.
> Dazu braucht es aber ein auf dem Client installiertes CA Zertifikat,
> damit das keine Fehler wirft.
Also allgm. immer, oder?
Zertifikate kann man sich in Win bestimmt irgendwo anzeigen lassen.
Kann man das herausfinden?
> Die Entscheidung, für die Verbindung **zum** Proxy https zu verwenden,
> verhindert hier nur MitM innerhalb des Firemnetzes.
Danke!
> > - Mit der debian VM komme ich auf klassischen Port raus.
> > Kann ich die Welt für mich irgendwie deutlich verbessern und was
> > muss ich tun?
> > Z.b ssh zu gitlab, github mit public key auth wäre schon cool
>
> Wenn Deine Firma entschieden hat, ausgehende ssh Verbindungen zu
> blockieren, wird sie sich vermutlich etwas dabei gedacht haben.
Und was könnte man sich gedacht haben?
> Die Optionen, sowas zu umgehen, könnten das Arbeitsverhältnis vermutlich
> beschleunigt terminieren.
Kann sein. Ist aber nicht relevant.
Ich möchte sicher nach draußen kommen (ohne MitM) und Quellen ziehen
können, die ich eh via http bekommen kann (Auch ohne Auth, aber pushes
sollen ohne MitM geschehen: Deswegen die Frage).
Das Arbeitsverhältnis wird vermutlich deutlich erhöht werden, wenn
Datenschutz Lecks auftauchen, weil die IT mitliest. :-)
(Ich denke mal das es die IT nicht einmal interessiert, aber http auth
und das man meine persönlichen passwörter tracken kann geht irgendwie
eben nicht.)
VG
Danke für Antwort!
Am Fr., 12. Jan. 2024 um 22:46 Uhr schrieb Ulf Volmer <u.vo...@u-v.de>:
>
> Am 12.01.24 um 22:28 schrieb Florian (flobee):
>
> > - [1] Ist das http für https anfragen via proxy Sicher? Oder kann die
> > IT mitlesen? 'Man in the middle'?
>
> Die 'IT' in Form des Proxy Betreibers kann sowieso mitlesen.
> Relevant ist hier die Verbindung zum Ziel:
>
> http: Proxy Betreiber kann mitlesen
> https: der Proxy verwendet die Direkt- Verbindung zum Ziel, der
> Betreiber kann üblicherweise nicht mitlesen. Ausnahme ist hier, wenn der
> Prxy die TLS Verbindung aufbricht, dann kann er auch wieder mitlesen.
> Dazu braucht es aber ein auf dem Client installiertes CA Zertifikat,
> damit das keine Fehler wirft.
Zertifikate kann man sich in Win bestimmt irgendwo anzeigen lassen.
Kann man das herausfinden?
> Die Entscheidung, für die Verbindung **zum** Proxy https zu verwenden,
> verhindert hier nur MitM innerhalb des Firemnetzes.
> > - Mit der debian VM komme ich auf klassischen Port raus.
> > Kann ich die Welt für mich irgendwie deutlich verbessern und was
> > muss ich tun?
> > Z.b ssh zu gitlab, github mit public key auth wäre schon cool
>
> Wenn Deine Firma entschieden hat, ausgehende ssh Verbindungen zu
> blockieren, wird sie sich vermutlich etwas dabei gedacht haben.
> Die Optionen, sowas zu umgehen, könnten das Arbeitsverhältnis vermutlich
> beschleunigt terminieren.
Ich möchte sicher nach draußen kommen (ohne MitM) und Quellen ziehen
können, die ich eh via http bekommen kann (Auch ohne Auth, aber pushes
sollen ohne MitM geschehen: Deswegen die Frage).
Das Arbeitsverhältnis wird vermutlich deutlich erhöht werden, wenn
Datenschutz Lecks auftauchen, weil die IT mitliest. :-)
(Ich denke mal das es die IT nicht einmal interessiert, aber http auth
und das man meine persönlichen passwörter tracken kann geht irgendwie
eben nicht.)
VG
Florian (flobee)
Jan 13, 2024, 6:40:05 PMJan 13
to
Hi
Am Sa., 13. Jan. 2024 um 20:27 Uhr schrieb Ulf Volmer <u.vo...@u-v.de>:
>
> Am 12.01.24 um 23:34 schrieb Florian (flobee):
> >> http: Proxy Betreiber kann mitlesen
> >> https: der Proxy verwendet die Direkt- Verbindung zum Ziel, der
> >> Betreiber kann üblicherweise nicht mitlesen. Ausnahme ist hier, wenn der
> >> Prxy die TLS Verbindung aufbricht, dann kann er auch wieder mitlesen.
> >> Dazu braucht es aber ein auf dem Client installiertes CA Zertifikat,
> >> damit das keine Fehler wirft.
> > Also allgm. immer, oder?
> Das dürfte eher die Ausnahm sein.
> Sowieso nur, wenn private Internet- Nutzung explizit ausgeschlossen
> wurde. Und wenn das Unternehmen einen BR hat, hat das zustimmungspflichtig.
> Aber IANAL.
---------^^^^^^^ Was?
> > Zertifikate kann man sich in Win bestimmt irgendwo anzeigen lassen.
> > Kann man das herausfinden?
> -> certmgr.msc. Ist hier aber fürchterlich Off- Topic.
Danke!
Mein wichtigste Frage, die Vermutlich utopisch lang zur Beantwortung
braucht, aber vielleicht hast Du ein, zwei links zum Verständnis für
mich?:
Am Sa., 13. Jan. 2024 um 20:27 Uhr schrieb Ulf Volmer <u.vo...@u-v.de>:
>
> Am 12.01.24 um 23:34 schrieb Florian (flobee):
> >> http: Proxy Betreiber kann mitlesen
> >> https: der Proxy verwendet die Direkt- Verbindung zum Ziel, der
> >> Betreiber kann üblicherweise nicht mitlesen. Ausnahme ist hier, wenn der
> >> Prxy die TLS Verbindung aufbricht, dann kann er auch wieder mitlesen.
> >> Dazu braucht es aber ein auf dem Client installiertes CA Zertifikat,
> >> damit das keine Fehler wirft.
> > Also allgm. immer, oder?
> Sowieso nur, wenn private Internet- Nutzung explizit ausgeschlossen
> wurde. Und wenn das Unternehmen einen BR hat, hat das zustimmungspflichtig.
> Aber IANAL.
---------^^^^^^^ Was?
> > Zertifikate kann man sich in Win bestimmt irgendwo anzeigen lassen.
> > Kann man das herausfinden?
Danke!
Mein wichtigste Frage, die Vermutlich utopisch lang zur Beantwortung
braucht, aber vielleicht hast Du ein, zwei links zum Verständnis für
mich?:
>> Wenn Deine Firma entschieden hat, ausgehende ssh Verbindungen zu
>> blockieren, wird sie sich vermutlich etwas dabei gedacht haben.
> Und was könnte man sich gedacht haben?
VG Florian
>> blockieren, wird sie sich vermutlich etwas dabei gedacht haben.
> Und was könnte man sich gedacht haben?
Florian (flobee)
Jan 14, 2024, 10:10:04 AMJan 14
to
Hi
Am So., 14. Jan. 2024 um 10:16 Uhr schrieb Ulf Volmer <u.vo...@u-v.de>:
> > ---------^^^^^^^ Was?
>
> https://martinvogel.de/lexikon/ianal.html
Das ist Coo! (-:
Am So., 14. Jan. 2024 um 10:16 Uhr schrieb Ulf Volmer <u.vo...@u-v.de>:
>
> On 14.01.24 00:29, Florian (flobee) wrote:
> > Hi
> >
> > Am Sa., 13. Jan. 2024 um 20:27 Uhr schrieb Ulf Volmer <u.vo...@u-v.de>:
> >> Aber IANAL.
> On 14.01.24 00:29, Florian (flobee) wrote:
> > Hi
> >
> > Am Sa., 13. Jan. 2024 um 20:27 Uhr schrieb Ulf Volmer <u.vo...@u-v.de>:
> > ---------^^^^^^^ Was?
>
> https://martinvogel.de/lexikon/ianal.html
Das ist Coo! (-:
0 new messages