Hello! Ezt a hibauzenetet kaptam: SSL handshake failed on the server side; error='error:1408F455:SSL routines:lib(20):SSL3_GET_RECORD:func(143):decryption failed or bad record mac:reason(1109)' Ez arra utal, hogy az elerni kivant szerver nem ismeri az ssl3-mat? Mit tudok tenni? -- Udvozlettel Zsiga
On Fri, Jun 28, 2002 at 11:35:06AM +0200, Kosa Attila wrote:
Hello! Ezt a hibauzenetet kaptam: SSL handshake failed on the server side; error='error:1408F455:SSL routines:lib(20):SSL3_GET_RECORD:func(143):decryption failed or bad record mac:reason(1109)'
Ez arra utal, hogy az elerni kivant szerver nem ismeri az ssl3-mat? Mit tudok tenni?
nem. szo szerint leforditva annyit jelent, hogy a masik oldal altal kuldott csomagon levo MAC ertek nem stimmel. A MAC a csomag integritasat hivatott vedeni. Milyen openssl verzio? Az uzenetet en nem talalom sem a 0.9.6a-ban sem a 0.9.6b-ben. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
On Fri, Jun 28, 2002 at 11:55:46AM +0200, Balazs Scheidler wrote:
On Fri, Jun 28, 2002 at 11:35:06AM +0200, Kosa Attila wrote:
Ezt a hibauzenetet kaptam: SSL handshake failed on the server side; error='error:1408F455:SSL routines:lib(20):SSL3_GET_RECORD:func(143):decryption failed or bad record mac:reason(1109)'
nem. szo szerint leforditva annyit jelent, hogy a masik oldal altal kuldott csomagon levo MAC ertek nem stimmel. A MAC a csomag integritasat hivatott vedeni. Milyen openssl verzio? Az uzenetet en nem talalom sem a 0.9.6a-ban sem a 0.9.6b-ben.
openssl 0.9.6c-1 Mit tehetek, hogy meg lehessen nezni az adott weboldalt? (Speciel pont a www.ibm.com egyik lapjat nem erem el.) -- Udvozlettel Zsiga
On Fri, Jun 28, 2002 at 11:55:46AM +0200, Balazs Scheidler wrote:
On Fri, Jun 28, 2002 at 11:35:06AM +0200, Kosa Attila wrote:
Hello! Ezt a hibauzenetet kaptam: SSL handshake failed on the server side; error='error:1408F455:SSL routines:lib(20):SSL3_GET_RECORD:func(143):decryption failed or bad record mac:reason(1109)'
Ez arra utal, hogy az elerni kivant szerver nem ismeri az ssl3-mat? Mit tudok tenni?
nem. szo szerint leforditva annyit jelent, hogy a masik oldal altal kuldott csomagon levo MAC ertek nem stimmel. A MAC a csomag integritasat hivatott vedeni. Milyen openssl verzio? Az uzenetet en nem talalom sem a 0.9.6a-ban sem a 0.9.6b-ben.
megtalaltam. a 0.9.6d-ben. ez a kodreszlet triggereli: if ((bs != 1) && !send) { i=rec->data[l-1]+1; /* SSL 3.0 bounds the number of padding bytes by the block size; * padding bytes (except that last) are arbitrary */ if (i > bs) { /* Incorrect padding. SSLerr() and ssl3_alert are done * by caller: we don't want to reveal whether this is * a decryption error or a MAC verification failure * (see http://www.openssl.org/~bodo/tls-cbc.txt) */ return -1; } rec->length-=i; } bs a block meret, a send azt jelenti, hogy kuldott vagy fogadott csomagrol van szo. Itt fogadott csomag, aminek hibas a padding-je. A padding byteok szama nagyobb, mint a blokkmeret. Ugyanez az ellenorzes megvan a 0.9.6b-ben is (csak mas a hibakodja, a fenti url irja le miert van a valtozas) A hiba oka legvaloszinubb valami hibas TLS1 megvalositas a masik oldalon, esetleg tamadasi kiserlet (szinten a fenti url-n van leirva), bar ez eleg kevesse valoszinu. Ki kellene iratni az i erteket, valahogy igy: if ((bs != 1) && !send) { i=rec->data[l-1]+1; fprintf(stderr, "hibas padding, i=%d, bs=%d\n", i, bs); /* SSL 3.0 bounds the number of padding bytes by the block size; * padding bytes (except that last) are arbitrary */ if (i > bs) { /* Incorrect padding. SSLerr() and ssl3_alert are done * by caller: we don't want to reveal whether this is * a decryption error or a MAC verification failure * (see http://www.openssl.org/~bodo/tls-cbc.txt) */ return -1; } rec->length-=i; } Az stderr megjelenik a zorp logjaban. Jo lenne meg a masik oldal tipusa, IIS, esetleg valami mas? Meg tudod mondani, hogy pontosan milyen szolgaltatas ez? Esetleg en is elerem? -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
On Fri, Jun 28, 2002 at 12:17:57PM +0200, Balazs Scheidler wrote:
On Fri, Jun 28, 2002 at 11:55:46AM +0200, Balazs Scheidler wrote:
vedeni. Milyen openssl verzio? Az uzenetet en nem talalom sem a 0.9.6a-ban sem a 0.9.6b-ben.
megtalaltam. a 0.9.6d-ben. ez a kodreszlet triggereli:
0.9.6c-1 woody-bol backportoltam.
Az stderr megjelenik a zorp logjaban. Jo lenne meg a masik oldal tipusa, IIS, esetleg valami mas?
Meg tudod mondani, hogy pontosan milyen szolgaltatas ez? Esetleg en is elerem?
https://commerce-04.www.ibm.com/cgi-bin/ncommerce3/ExecMacro/s_overview.d2w/... -- Udvozlettel Zsiga
On Fri, Jun 28, 2002 at 12:21:50PM +0200, Kosa Attila wrote:
On Fri, Jun 28, 2002 at 12:17:57PM +0200, Balazs Scheidler wrote:
On Fri, Jun 28, 2002 at 11:55:46AM +0200, Balazs Scheidler wrote:
vedeni. Milyen openssl verzio? Az uzenetet en nem talalom sem a 0.9.6a-ban sem a 0.9.6b-ben.
megtalaltam. a 0.9.6d-ben. ez a kodreszlet triggereli:
0.9.6c-1 woody-bol backportoltam.
Az stderr megjelenik a zorp logjaban. Jo lenne meg a masik oldal tipusa, IIS, esetleg valami mas?
Meg tudod mondani, hogy pontosan milyen szolgaltatas ez? Esetleg en is elerem?
https://commerce-04.www.ibm.com/cgi-bin/ncommerce3/ExecMacro/s_overview.d2w/...
ok, ugy nez ki, hogy openssl hiba, sikerult reprodukalnom: bazsi@kuka:~$ openssl s_client -connect commerce-04.www.ibm.com:443 CONNECTED(00000003) depth=1 /C=US/O=Equifax Secure Inc/CN=Equifax Secure E-Business CA-2 verify error:num=20:unable to get local issuer certificate verify return:0 27919:error:1408F455:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac:s3_pkt.c:450: reportolom az openssl fejlesztoknek. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
On Fri, Jun 28, 2002 at 12:23:50PM +0200, Balazs Scheidler wrote:
On Fri, Jun 28, 2002 at 12:21:50PM +0200, Kosa Attila wrote:
megtalaltam. a 0.9.6d-ben. ez a kodreszlet triggereli:
0.9.6c-1 woody-bol backportoltam.
reportolom az openssl fejlesztoknek.
Koszi. Neked a "d" verzioval is elojott ezek szerint? Akkor hogyan tudom megoldani a problemas lap elereset? Csak sima pluggal? -- Udvozlettel Zsiga
On Fri, Jun 28, 2002 at 12:32:52PM +0200, Kosa Attila wrote:
On Fri, Jun 28, 2002 at 12:23:50PM +0200, Balazs Scheidler wrote:
On Fri, Jun 28, 2002 at 12:21:50PM +0200, Kosa Attila wrote:
megtalaltam. a 0.9.6d-ben. ez a kodreszlet triggereli:
0.9.6c-1 woody-bol backportoltam.
reportolom az openssl fejlesztoknek.
Koszi.
Neked a "d" verzioval is elojott ezek szerint? Akkor hogyan tudom megoldani a problemas lap elereset? Csak sima pluggal?
igen, arra az egy ip-re plugold ki. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
On Fri, Jun 28, 2002 at 12:35:43PM +0200, Balazs Scheidler wrote:
On Fri, Jun 28, 2002 at 12:32:52PM +0200, Kosa Attila wrote:
Neked a "d" verzioval is elojott ezek szerint? Akkor hogyan tudom megoldani a problemas lap elereset? Csak sima pluggal?
igen, arra az egy ip-re plugold ki.
De jo. Mire megcsinaltam, hogy el lehessen erni, addigra nem megy a lap :) Vagy csak nekem adja ezt a hibauzenetet? https://commerce-04.www.ibm.com/cgi-bin/ncommerce3/ExecMacro/s_overview.d2w/... DTWF050E: Net.Data is unable to locate the HTML block specification in the URL. Mas el tudja erni? Mert ha igen, akkor meg valamin allitanom kellene... -- Udvozlettel Zsiga
Sziasztok! LAssan mar mindent feladok, Scott is probalt mar segiteni, de tobb szem tobbet lat alapon a kovetkezo problemat vetnem fel: - adott egy 10.0.0.0-s alhalo, hozza kifele egy fix IP-s ADSL - adott most mar a vegletekig lebutitott ipchains (csak redirect van mar) es Zorp (csak HTTP szures, abban sincs kulon osztaly) Kernel: 2.2.21, a siterol letoltott patchek hozzaadva, freeswan.org-rol leszedve a 1.97-es valtozat, abbol forgatva a binaris, make menugoval megcsinalva. A csomaszureshez: CONFIG_IP_FIREWALL=y -> kotelezo ugyebar CONFIG_IP_FIREWALL_NETLINK=y CONFIG_NETLINK_DEV=y CONFIG_IP_ROUTE_FWMARK=y -> csak ugy CONFIG_IP_TRANSPARENT_PROXY=y - > kotelezo ugyebar CONFIG_IP_MASQUERADE=y -> megszokas Kernel telpitve, szukseges opciok: /proc/sys/net/ipv4/ip_forward 1 /proc/sys/net/ipv4/conf/all/rp_filter 0 es ez minden if-re igaz Interfacek: eth0 - kell a ppp0-nak, ADSL kovetelmeny eth1 - belso if lo - standard ppp0 - kifele biztositja a kapcsolatot, fix IP, ADSL instances.conf tartalma: intra --log-tags --verbose=5 -p /etc/zorp/policy.py A teszteles es orulet hataran levo policy.py tartalma: from Zorp.Core import * from Zorp.Http import * Zorp.firewall_name = 'zorp@inside' InetZone("intranet", "10.0.0.0/24", inbound_services=[], outbound_services=["intra_HTTP_inter"]), InetZone("internet","0.0.0.0/0", inbound_services=["intra_HTTP_inter"], outbound_services=[]) def intra(): Service("intra_HTTP_inter", HttpProxy) Listener(SockAddrInet("10.0.0.40", 51080), "intra_HTTP_inter") ipchainsben a kovetkezokeppen nez ki most: REDIRECT tcp ----l- 10.0.0.0/24 anywhere any -> www => 51080 De, hogy kulon lancon tartsam a dolgokat, voltak mar a kovetkezo szabalyok is: (ipchains-utils-szal es anelkul generalva) ipchains -A input -i eth1 ! -d 10.0.0.40/32 -j INtra ipchains -A INtra -d 0.0.0.0/0 80 -p tcp -j REDIRECT 51080 (es ugyanez logolva is) Routing tabla: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface nilus-Loopback0 * 255.255.255.255 UH 0 0 0 ppp0 10.0.0.0 * 255.255.255.0 U 0 0 0 eth1 default nilus-Loopback0 0.0.0.0 UG 0 0 0 ppp0 Windowson gw a 10.0.0.40, lokalis DNS van, command-bol fel tudja oldani a neveket/cimeket, DNS a 10.0.0.40-en levo BIND. Ami tortenik: Indulaskor a kovetkezo latszik a logban: Jun 28 16:55:35 rawhide intra[980]: core.info(5): zorp version 1.4.4 going down. Jun 28 16:55:37 rawhide intra[1169]: core.debug(0): Verbosity level: 5 Jun 28 16:55:37 rawhide intra[1169]: core.info(5): zorp version 1.4.4 starting up Jun 28 16:55:38 rawhide intra[1169]: core.debug(5): (zorp/nosession): Zone(intranet): outbound service=intra_HTTP_inter Jun 28 16:55:38 rawhide intra[1169]: core.debug(5): (zorp/nosession): Zone(internet): inbound service=intra_HTTP_inter Jun 28 16:55:38 rawhide intra[1169]: core.caps(5): (zorp/nosession): Changing process capabilities; caps='= cap_net_bind_service+ep cap_net_admin+p' Jun 28 16:55:38 rawhide intra[1169]: core.caps(5): (zorp/nosession): Changing process capabilities; caps='= cap_net_bind_service,cap_net_admin+ep' Jun 28 16:55:38 rawhide intra[1169]: core.caps(5): (zorp/nosession): Resetting process capabilities; caps='= cap_net_bind_service,cap_net_admin+p' Ha kozvetlenul csatlakozom a proxyhoz (Exploderben proxy a 10.0.0.40, port a 51080) termeszetesen megakadalyoz, logban a kovetkezo latszik: Jun 28 13:00:54 rawhide intra[1114]: core.session(3): (zorp@valinal/intra_HTTP_i nter:0): Starting proxy instance; client_fd='9', client_address='AF_INET(10.0.0. 4:1138)', client_zone='Zone(intranet, 10.0.0.0/24)', client_local='AF_INET(10.0. 0.40:51080)' Jun 28 13:00:54 rawhide intra[1114]: core.session(4): (zorp@valinal/intra_HTTP_i nter:0/http): Proxy starting; class='HttpProxy', module='http' Jun 28 13:00:54 rawhide intra[1119]: core.policy(1): (zorp@valinal/intra_HTTP_in ter:0): Inbound service not permitted; service='intra_HTTP_inter', zone='Zone(in tranet, 10.0.0.0/24)' Jun 28 13:00:54 rawhide intra[1119]: http.debug(5): (zorp@valinal/intra_HTTP_int er:0/http): An error occurred, serving error file; filename='/usr/share/zorp/htt p/connecterror.html' Jun 28 13:00:54 rawhide intra[1119]: core.session(4): (zorp@valinal/intra_HTTP_i nter:0/http): Proxy ending; class='HttpProxy', module='http' Jun 28 13:00:54 rawhide intra[1119]: core.accounting(5): (zorp@valinal/intra_HTT P_inter:0): client: accounting info; duration='0', sent='842', received='297' Mikor az atiranyitasra hagyatkoztam (gw a 10.0.0.40, DNS a 10.0.0.40) akkor a kovetkezo jelent meg: Jun 28 12:26:21 rawhide intra[822]: core.session(3): (zorp@valinal/intra_HTTP_in ter:0): Starting proxy instance; client_fd='9', client_address='AF_INET(10.0.0.4 :1047)', client_zone='Zone(intranet, 10.0.0.0/24)', client_local='AF_INET(10.0.0 .40:51080)' Es megallt. Alakitottam az ipchainst es a kovetkozot ertem el: - meg logolassal sem latszik az, hogy egy csomag at lett volna iranyitva, mindegy, hogy az input lancon vagy INtra lancon iranyitom at a zorp portjara Ami furcsa: Ugyanezek a csomagok, ugyanezek a szabalyok (ipchains, zorp) berelt vonalon mennek, termeszetesen egy ket parameter mas, peldaul ott tudom ,hogy milyen network es broadcast stb cim van a kulso interfacen, igy tudom finomitani a szabalyokat a szuresre. Hardware: ASUS alaplap, Celeron II proci. Csak azert irom le, mert erdekes: alapertlemezesekent a REalTek halokartyak 0-as(!) IRQ-t kaptak, mind a ketto! BIOS buzergalas ota nem, de azota minden kis hardware valtozas utan (pl uj billentyu) felhozza a BIOS setupot.... Mit neztem el, de nagyon? Mar nem tudokm asra gondolni, mint valami nagyon trivialisra.... Udv, Ago
On Fri, Jun 28, 2002 at 02:52:16PM +0200, Deim Agoston wrote:
instances.conf tartalma: intra --log-tags --verbose=5 -p /etc/zorp/policy.py
Esetleg vehetned feljebb a verbose szintet.
A teszteles es orulet hataran levo policy.py tartalma:
En abszolut nem igy szoktam irni a konfigfajlt, persze ebbol nem kovetkezik, hogy emiatt nem megy :) De esetleg kiprobalhatnad a kovetkezot: from Zorp.Core import * from Zorp.Http import * from Zorp.Plug import * Zorp.firewall_name = 'zorp@inside' InetZone("webezes", "10.0.0.0/24", inbound_services=[], outbound_services=["intra_http"]) InetZone("internet", "0.0.0.0/0", inbound_services=["intra_http"], outbound_services=[]) class IntraHttp(HttpProxy): def config(self): HttpProxy.config(self) self.transparent_mode = 1 Service("intra_http", IntraHttp, InbandRouter()) Listener(SockAddrInet("10.0.0.40", 51080), "intra_http") _Nagyon_ allergias a tabulatorok es/vagy szokozok hasznalatara!
ipchainsben a kovetkezokeppen nez ki most: REDIRECT tcp ----l- 10.0.0.0/24 anywhere any -> www => 51080
Az volt regebben az allaspont, hogy azt a portot amire redirectelunk, azt meg kell vedeni, hogy kozvetlenul senki ne csatlakozhasson hozza. Ez megvaltozott? En siman (kezzel) kiprobalnam ezt: ipchains -F ; ipchains -X ; ipchains -P input ACCEPT ; ipchains -P output ACCEPT ; ipchains -P forward REJECT ; ipchains -A input -p tcp -i eth1 --dport 51080 -j DENY ipchains -A input -p udp -i eth1 --dport 51080 -j DENY ipchains -A input -p tcp -i eth1 -s 10.0.0.0/8 1024: -d 0/0 80 -j REDIRECT 51080 -l
Mit neztem el, de nagyon? Mar nem tudokm asra gondolni, mint valami nagyon trivialisra....
Nem tudom :( Probald ki amiket kuldtem, es meseld el az eredmenyt. Nagy keres lenne, hogy uj levelet uj levelkent irjal (ne csak a subject atirasaval)? -- Udvozlettel Zsiga
instances.conf tartalma: intra --log-tags --verbose=5 -p /etc/zorp/policy.py Esetleg vehetned feljebb a verbose szintet. Ott mar foleg a C hivast latok foleg...
En abszolut nem igy szoktam irni a konfigfajlt, persze ebbol nem kovetkezik, hogy emiatt nem megy :) De esetleg kiprobalhatnad a kovetkezot: En is igy irtam eloszor, itt mar csak a sortoresek miatt raktam ossze. De igy is megprobaltam azert, mielott elkuldom. Az indulaskor a logban amugy is megjelent a
Service("intra_http", IntraHttp, InbandRouter()) Igen, ez fog segiteni. Kozben mar beszeltem Sasaval aki ecsetelte a Windowsok stackjenek finomsagait, foleg proxy teren... Erdekes Win2k alatt nem volt problema, Me-vel igen. 9x-el nem lett leprobalva. Linux alatt ment :-) Bevitt a kollega egy noteszt es ki tudott menni.
_Nagyon_ allergias a tabulatorok es/vagy szokozok hasznalatara! SciTecben irom a szabalyokat, miota eloszor szivtam :-) Meg figyelek is.
ipchainsben a kovetkezokeppen nez ki most: REDIRECT tcp ----l- 10.0.0.0/24 anywhere any -> www => 51080
Az volt regebben az allaspont, hogy azt a portot amire redirectelunk, azt meg kell vedeni, hogy kozvetlenul senki ne csatlakozhasson hozza. Ez megvaltozott? Nem valtozott. De a tesztnel ez meg megengedheto volt...
En siman (kezzel) kiprobalnam ezt: ipchains -F ; ipchains -X ; ipchains -P input ACCEPT ; ipchains -P output ACCEPT ; ipchains -P forward REJECT ; ipchains -A input -p tcp -i eth1 --dport 51080 -j DENY ipchains -A input -p udp -i eth1 --dport 51080 -j DENY ipchains -A input -p tcp -i eth1 -s 10.0.0.0/8 1024: -d 0/0 80 -j REDIRECT 51080 -l Ezt inkabb elore kellene irni, nem?
Mit neztem el, de nagyon? Mar nem tudokm asra gondolni, mint valami nagyon trivialisra....
Nem tudom :( Probald ki amiket kuldtem, es meseld el az eredmenyt. Nagy keres lenne, hogy uj levelet uj levelkent irjal (ne csak a subject atirasaval)? Nem :-) A valogatasnal gond volt? Egyszerubb mindig nyomni egy reply-t, mint bepotyogni a cimet... En csak egybetus aliasokat hasznalok es azok mar mind elfogytak.... Udv, Ago
On Fri, Jun 28, 2002 at 03:44:33PM +0200, Kosa Attila <atkosa@shinwa.hu> wrote:
En siman (kezzel) kiprobalnam ezt: ipchains -F ; ipchains -X ; ipchains -P input ACCEPT ; ipchains -P output ACCEPT ; ipchains -P forward REJECT ; ipchains -A input -p tcp -i eth1 --dport 51080 -j DENY ipchains -A input -p udp -i eth1 --dport 51080 -j DENY ipchains -A input -p tcp -i eth1 -s 10.0.0.0/8 1024: -d 0/0 80 -j REDIRECT 51080 -l Ha jobban belegondolok, jo szabalyrendszerrel mar az elejen ki lehet szurni a dolgokat. mason nem johet 10.0.0.0/24-rol kapcsolat, mint a eth1, 127.0.0.0/8-rol nem johet mashonnan, mint lo-rol stb. Ezt mindig igy csinalom a ipchains felhuzasanak kezdeten. De egy tsztnel, ahol amugy sem volt forgalom, szerintem nem gaz amit csinaltam, ha mar megy minden akkor finomithatunk is, illetve a csomagszurot updateljuk... Udv, Ago
On 2002 Jun 28, Deim Agoston wrote:
Ha jobban belegondolok, jo szabalyrendszerrel mar az elejen ki lehet szurni a dolgokat. mason nem johet 10.0.0.0/24-rol kapcsolat, mint a eth1, 127.0.0.0/8-rol nem johet mashonnan, mint lo-rol stb. Ezt mindig igy csinalom a
ezt hivjak spoof szuresnek;-) Höltzl Péter -- Ho:ltzl Pe'ter | Tel: +36 1 371-0540 | GnuPG Fingerprint: BalaBit IT Kft | Mobil: +36 20 366-9667 | DB30 5E5B 8777 C06F 5A1F holtzl.peter@balabit.hu | http://www.balabit.hu/ | 4586 CEAF 9678 4A89 CFD6
participants (4)
-
Balazs Scheidler
-
Deim Agoston
-
HOLTZL Peter
-
Kosa Attila