Forum » Informacijska varnost » Omrežni protokol - nadomestilo https
Omrežni protokol - nadomestilo https
marjan_h ::
Tole je mogoče vprašanje za višji nivo, vendar če pogledamo protokol https, ki omogoča prenos podatkov med dvema vozliščema in se ga tudi uporablja za API. Zakaj bi potrebovali še ostale protokole?
Če primerjamo z ssh (to je samo primer), ki omogoča prenos gesla in dostop do ukaznega poziva.
Lahko bi to simulirali preko https recimo JSON:
Primer zahtevka:
{ "username":"user", "password": "sha256(pass)", "command": "ls"}
Primer odziva:
{"directory": ["Documents"], "file": ["script.py", "test.txt"]}
Vem, da obstajajo TCP/IP nivoji ter da imamo porte za povezovanje procesov. Ampak tudi gesla ter XML ali JSON podatke prenašamo preko https. Imamo lahko univerzalen protokol za vse?
Če primerjamo z ssh (to je samo primer), ki omogoča prenos gesla in dostop do ukaznega poziva.
Lahko bi to simulirali preko https recimo JSON:
Primer zahtevka:
{ "username":"user", "password": "sha256(pass)", "command": "ls"}
Primer odziva:
{"directory": ["Documents"], "file": ["script.py", "test.txt"]}
Vem, da obstajajo TCP/IP nivoji ter da imamo porte za povezovanje procesov. Ampak tudi gesla ter XML ali JSON podatke prenašamo preko https. Imamo lahko univerzalen protokol za vse?
SasoS ::
Zato ker računalniki niso ljudje in ne berejo teksta, pač pa procesirajo binarne podatke.
Če pošiljaš nekaj v stilu JSON-a, moraš najprej validirat da je format OK, potem pa parsirat string v objekte, ki jih lahko šele za tem uporabiš. Če je protokol orientiran binarno, potem je učinkovitejši, hitrejši in porabi manj bandwidtha.
Če pošlješ http zahtevek, imaš za vsak zahtevek header, npr:
Vidiš koliko crapa preden sploh prideš do HTML začetka? Poleg tega http ni stateful ne ve kje je ostal, vsak request je sam zase.
SSH ravno tako izmenjuje sporočila (messages), ampak ne rabiš sledit JSON ali XML shemam ker za to ni potrebe. In objekte lahko direktno parsiraš. Recimo en primer kako bi zgledal ukaz:
https://comp.security.ssh.narkive.com/2...
ni potrebe da imaš '{' in '}', da atribute tagiraš z "username" in "password", vse to je odvečna navlaka iz JSON-a... The worst case v računalništvu je, da nekaj tlačiš v obliko, ki za to ni primerna, zato da bo "univerzalno"...
Če pošiljaš nekaj v stilu JSON-a, moraš najprej validirat da je format OK, potem pa parsirat string v objekte, ki jih lahko šele za tem uporabiš. Če je protokol orientiran binarno, potem je učinkovitejši, hitrejši in porabi manj bandwidtha.
Če pošlješ http zahtevek, imaš za vsak zahtevek header, npr:
---request begin---
GET / HTTP/1.1
User-Agent: Wget/1.14 (linux-gnu)
Accept: */*
Host: slo-tech.com
Connection: Keep-Alive
---request end---
---response begin---
HTTP/1.1 200 OK
Server: nginx
Date: Fri, 15 Dec 2023 21:38:28 GMT
Content-Type: text/html; charset=iso-8859-2
Transfer-Encoding: chunked
Connection: keep-alive
ETag: 0-0-1-1702675725
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Expect-CT: report-uri="https://sentry.ilol.si/api/2/security/?...
Referrer-Policy: no-referrer
Content-Security-Policy-Report-Only: default-src 'self' https://static.slo-tech.com https://zy.si https://push.slo-tech.com; script-src 'self' 'unsafe-inline' https://static.slo-tech.com https://oglasi.slo-tech.com https://zy.si; style-src 'self' data: 'unsafe-inline' static.slo-tech.com; img-src 'self' data: https://* http://* https://static.slo-tech.com https://oglasi.slo-tech.com https://zy.si; connect-src 'self' https://oglasi.slo-tech.com https://push.slo-tech.com wss://push.slo-tech.com ws://push.slo-tech.com https://zy.si; frame-src 'self' https://oglasi.slo-tech.com https://www.youtube-nocookie.com; worker-src 'none'; frame-ancestors 'none'; form-action 'self'; upgrade-insecure-requests; sandbox; report-uri https://sentry.ilol.si/api/2/security/?...
---response end---
HTTP/1.1 200 OK
Server: nginx
Date: Fri, 15 Dec 2023 21:38:28 GMT
Content-Type: text/html; charset=iso-8859-2
Transfer-Encoding: chunked
Connection: keep-alive
ETag: 0-0-1-1702675725
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Expect-CT: report-uri="https://sentry.ilol.si/api/2/security/?...
Referrer-Policy: no-referrer
Content-Security-Policy-Report-Only: default-src 'self' https://static.slo-tech.com https://zy.si https://push.slo-tech.com; script-src 'self' 'unsafe-inline' https://static.slo-tech.com https://oglasi.slo-tech.com https://zy.si; style-src 'self' data: 'unsafe-inline' static.slo-tech.com; img-src 'self' data: https://* http://* https://static.slo-tech.com https://oglasi.slo-tech.com https://zy.si; connect-src 'self' https://oglasi.slo-tech.com https://push.slo-tech.com wss://push.slo-tech.com ws://push.slo-tech.com https://zy.si; frame-src 'self' https://oglasi.slo-tech.com https://www.youtube-nocookie.com; worker-src 'none'; frame-ancestors 'none'; form-action 'self'; upgrade-insecure-requests; sandbox; report-uri https://sentry.ilol.si/api/2/security/?...
Registered socket 3 for persistent reuse.
URI content encoding = 'iso-8859-2'
!DOCTYPE HTML...
Vidiš koliko crapa preden sploh prideš do HTML začetka? Poleg tega http ni stateful ne ve kje je ostal, vsak request je sam zase.
SSH ravno tako izmenjuje sporočila (messages), ampak ne rabiš sledit JSON ali XML shemam ker za to ni potrebe. In objekte lahko direktno parsiraš. Recimo en primer kako bi zgledal ukaz:
https://comp.security.ssh.narkive.com/2...
ni potrebe da imaš '{' in '}', da atribute tagiraš z "username" in "password", vse to je odvečna navlaka iz JSON-a... The worst case v računalništvu je, da nekaj tlačiš v obliko, ki za to ni primerna, zato da bo "univerzalno"...
Lonsarg ::
Ja vsako stvar je možno narediti na tisoč načinov in preko tisoč različnih protokolov, ampak za vsako stvar obstaja zgolj ozek nabor opcije, velikokrat zgolj ena, ki je optimalna pot. In ne niti slučajno ni smiselno vse združit v en protokol, z razlogom obstajajo layerji. Z razlogom obstajajo tudi različne rešitve na istem layerju, ker niso vse primerne vedno in ker kaka "konkurenca" tudi na nivoju protokolov pride prav.
Kar se tiče ssh ali kakih alternativnih protokolov ki so svoj layer nad http pa ja, dandanes ssh res nima več toliko prednosti kot jih je imel, ampak za določene specifične use case pač še vedno je prava izbira.
Definitivno pa če greš delat kak nov protokol dandanes za bazo vzameš http, ker je tako iz časovnega kot varnostnega stališča neumno izumljat toplo vodo na nivoju transport security in vzameš neko splošno bazo ki je popularna, podprta in ki se tudi še aktivno razvija. HTTP/3 je super zadeva, @SasoS tudi stateful problem so rešili z HTTP/3.
Kar se tiče ssh ali kakih alternativnih protokolov ki so svoj layer nad http pa ja, dandanes ssh res nima več toliko prednosti kot jih je imel, ampak za določene specifične use case pač še vedno je prava izbira.
Definitivno pa če greš delat kak nov protokol dandanes za bazo vzameš http, ker je tako iz časovnega kot varnostnega stališča neumno izumljat toplo vodo na nivoju transport security in vzameš neko splošno bazo ki je popularna, podprta in ki se tudi še aktivno razvija. HTTP/3 je super zadeva, @SasoS tudi stateful problem so rešili z HTTP/3.
Zgodovina sprememb…
- spremenil: Lonsarg ()
DamijanD ::
pa tudi zgodovinsko gledano http ni bil prvi protokol. Tako da nekoč sploh ni bil opcija, json je pa sploh prišel šele mnogo kasneje.
Lonsarg ::
http je bil narejen za višjenivojske aplikacije, da ne rabijo te same se ubadat z networkom. Ampak ni bil targetiran na performance in zato so highperformance aplikacije vedno kaj drugega uporabljale (ali direkt UDP ali kaj posredno čez UDP). Z http/3 verzijo, ki teče na UDPju in je stateless z reusable connectioni je http postal performančen in s tem je za veliko večino scenarijev, tudi high-performance, odpadla potreba da rabijo kaj drugega kot http. No vsaj za 99% scenarijev, vedno bo ostal kak 1% scenarijev ki rabijo tailored zadevo. Tudi za compression http3 poskrbi, tak da je tudi json preko http/3 postal zelo primerljiv z gRPC naprimer, še vedno ima gRPC nekaj prednosti ampak se je ta prednost precej zmanjšala.
Zgodovina sprememb…
- spremenil: Lonsarg ()
SasoS ::
Transport security rešiš z TLS, ampak je res da razvoj custom protokola zahteva čas. Definirat moraš sporočila, naredit state machine, itd...v večini primerov je zato pač lažje naredit rest/json api preko http.
Lonsarg ::
Ja dejansko bodo sčasoma najbrž low-level protokoli kot je ssh3 prisiljeni postopoma šiftat na http3(quic) layer, ker so drugi porti/protokoli vedno bolj blokirani/omejeni dandanes. Overhead za tak šift je glede na današnje zmogljivosti networka itak minimalen (overhead pri http1/2 pa je bil precej večji).
Zgodovina sprememb…
- spremenil: Lonsarg ()
pegasus ::
Slab argument. Nas bo samo prisilil deployat več L7 firewallov z aktivnim MITM za enforcanje politik v kriptiranih streamih. Si res želiš tega?
Edina v tem repozitoriju prikazana prednost ssh3 je hitrejša avtentikacija. Je komu kdaj bila hitrost avtentikacije bottleneck pri uporabi ssh? IMHO tole rešuje problem, ki ne obstaja... in bo zato ssh3 ostal samo akademska zanimivost.
Edina v tem repozitoriju prikazana prednost ssh3 je hitrejša avtentikacija. Je komu kdaj bila hitrost avtentikacije bottleneck pri uporabi ssh? IMHO tole rešuje problem, ki ne obstaja... in bo zato ssh3 ostal samo akademska zanimivost.
Lonsarg ::
Slab argument. Nas bo samo prisilil deployat več L7 firewallov z aktivnim MITM za enforcanje politik v kriptiranih streamih. Si res želiš tega?Nima veze ali je ssh preko httpja ali svojega porta in protokola, v vsakem primeru je v http prometu lahko marsikaj. In tudi že je, ni nobene poti več nazaj. Per protokol/port ločevanje prometa je preteklost, že sedaj, http/ssh tle ne igra sploh vloge. V bistvu je per protokol/port security slab že od vsega začetka.
In ne, to se ne rešuje z MITM, ampak se rešuje z per app/per server security oziroma nasploh z ekstra layerji varnosti, zero trust in podobno. To da se obesiš na en layer, network, in probaš tam vse ujet je preteklost.
Zgodovina sprememb…
- spremenil: Lonsarg ()
Vredno ogleda ...
| Tema | Ogledi | Zadnje sporočilo | |
|---|---|---|---|
| Tema | Ogledi | Zadnje sporočilo | |
| » | Kongresno zaslišanje tehnoloških velikanov to pot odločnejšeOddelek: Novice / NWO | 7809 (5511) | mailer |
| » | Javascript DOM based XSS vulnerabilityOddelek: Programiranje | 3175 (2597) | MrStein |
| » | Content-Security-Policy problemOddelek: Izdelava spletišč | 1582 (1399) | poweroff |
| » | dropbox vprašanje ?Oddelek: Omrežja in internet | 7450 (5720) | fulgur |
| » | slo-tech certifikatOddelek: Slo-Tech | 1752 (1212) | MUC |