Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Witam serdecznie. W odniesieniu do słów kolegi [b]yossarian'a[/b] ("[i]Ta strona z testem chyba nie jest do końca wiarygodna."[/i]), zamieszczam odnośnik do innej witryny, tym razem - mam nadzieję - wiarygodnej; [url=https://www.ssllabs.com/ssltest/index.html][color=blue]ssltest/analyze[/color][/url] :- [i])[/i]
Pozdrawiam.
Offline
Z tego co widzę po Claws-mailu certyfikat do usługi IMAP Gmaila i Yahoo się nie zmienił. Zmienił się certyfikat Interii, więc tutaj warto zmienić hasło.
Offline
Nie wiem, czy to jest błąd specyficzny dla wersji w OpenBSD czy ogólnej, ale kolejny błąd:
http://www.openbsd.org/errata54.html
008: SECURITY FIX: April 12, 2014 All architectures
A use-after-free race condition in OpenSSL's read buffer may permit an attacker to inject data from one connection into another.
[url=http://ftp.openbsd.org/pub/OpenBSD/patches/5.4/common/008_openssl.patch]A source code patch exists which remedies this problem.[/url][/quote]
Na stronie OpenSSL nie ma o nim informacji.
Offline
To pewnie wyszło przy dogłebnym sprawdzaniu. Jakby nie patrzeć devy z openbsd mieli takową dziurę przez dwa lata. A ich hasło brzmi że kroją system na tyle na ile są w stanie zapewnić że możemy czuć się bezpieczni. Tak to jest jak się krytykuje innych na boku (Theo lubi odgryzać się na ekipie freebsd)
Offline
[quote=hello_world]To pewnie wyszło przy dogłebnym sprawdzaniu. Jakby nie patrzeć devy z openbsd mieli takową dziurę przez dwa lata. A ich hasło brzmi że kroją system na tyle na ile są w stanie zapewnić że możemy czuć się bezpieczni. Tak to jest jak się krytykuje innych na boku (Theo lubi odgryzać się na ekipie freebsd)[/quote]
Akurat tego zarządzania pamięcią w OpenSSL nie mogli wyłączyć, bo były z tym związane problemy. Niby była jakaś flaga podczas kompilacji, ale po jej włączeniu i używaniu takiego OpenSSL z np. Apachem, który jest mocno obciążony w logach roiło się od ostrzeżeń i nawet zerwanych połączeń. Poza tym ekipa OpenBSD jest bardzo mała, nie są w stanie wszystkiego sprawdzić.
Mi się podoba krytyka Theo, bo krytykuje konkretne rozwiązania. C [i]nie[/i] jest bezpiecznym językiem programowania, takich błędów w każdym dużym projekcie jest mnóstwo. Z tego powodu powstały odpowiednie zabezpieczenia, a to łatki na bibliotekę C, a to na właściwy kompilator, a to na jądro. A to własne zarządzanie pamięcią w OpenSSL powoduje, że nie zabezpieczają tego procesu. Nie można go w praktyce wyłączyć, bo bez niego OpenSSL źle działa.
Podobnie jak w przypadku pełnego, ślepego zaufania do sprzętowego generowania liczb (pseudo)losowych w starszych wersjach FreeBSD.
Offline
[url=http://niebezpiecznik.pl/post/o-bledach-programistow-i-testowaniu-oprogramowania-w-kontekscie-heartbleed/]O błędach programistów i testowaniu oprogramowania w kontekście Heartbleed[/url]
Offline
[b]drelbrown[/b] nie zgadzam się akurat z tym co napisali w tej kwestii na niebezpieczniku. żaden błąd a umyślna furtka, pewnie za dwa lata wyjdzie następna w wersji rzekomo poprawionej, której używamy teraz..;)
Pewno nie było im wygodnie już korzystać z tego sposobu i mają w zanadrzu coś lepszego, ujawnili rzekomą dziurę (patrz google, od razu śmierdzi przecież to pionek na usługach amerykańskich agencji), zrobili szum żeby zamydlić oczy tłuszczy a przemycają coś znacznie skuteczniejszego (niekoniecznie w ossl)...czysty [url=https://pl.wikipedia.org/wiki/Spin_%28socjotechnika%29]SPIN[/url] i odwrócenie uwagi...
Ostatnio edytowany przez menel (2014-04-15 15:13:18)
Offline
@menel
W praktyce to wygląda następująco:
1. Tajna służba produkuje gotowego backdoora czy rootkita, napisanego w ten sposób, że wrazie wykrycia, można uznać go jako błąd kodera.
2. Tajna służba pozyskuje do współpracy bardzo zaufanego członka danego projektu, który nie jest milionerem.
3. Zaufany członek projektu wrzuca „niespodziankę” do kodu w zamian za bańkę dolców i milczenie.
OpenSSL, zapewne w porównaniu do kernela, ma niewiele linijek kodu. Nie zdziwiłbym się jakby pojawiły się podobne rewelacje w Kernelu, Netfilterze, Grsecurity , SELinuksie, LUKS/dm-crypcie, można jeszcze sporo wymieniać.
Moim zdaniem, różnica, w tej kwestii, pomiędzy zamkniętym i otwartym kodem jest taka, że bardziej prawdopodobne jest wykrycie „niespodzianki” w otwartym. Tylko tyle i aż tyle.
Ostatnio edytowany przez drelbrown (2014-04-15 15:22:25)
Offline
Moim zdaniem, różnica, w tej kwestii, pomiędzy zamkniętym i otwartym kodem jest taka, że bardziej prawdopodobne jest wykrycie „niespodzianki” w otwartym.[/quote]
Czy to ma znaczenie po dwóch latach? xD
Offline
[quote=drelbrown]@menel
W praktyce to wygląda następująco:
1. Tajna służba produkuje gotowego backdoora czy rootkita, napisanego w ten sposób, że wrazie wykrycia, można uznać go jako błąd kodera.
2. Tajna służba pozyskuje do współpracy bardzo zaufanego członka danego projektu, który nie jest milionerem.
3. Zaufany członek projektu wrzuca „niespodziankę” do kodu w zamian za bańkę dolców i milczenie.
OpenSSL, zapewne w porównaniu do kernela, ma niewiele linijek kodu. Nie zdziwiłbym się jakby pojawiły się podobne rewelacje w Kernelu, Netfilterze, Grsecurity , SELinuksie, LUKS/dm-crypcie, można jeszcze sporo wymieniać.
Moim zdaniem, różnica, w tej kwestii, pomiędzy zamkniętym i otwartym kodem jest taka, że bardziej prawdopodobne jest wykrycie „niespodzianki” w otwartym. Tylko tyle i aż tyle.[/quote]
Kodu w OpenSSL jest ponad 450 tysięcy linii + 136 tysięcy linii wykorzystanych na komentarze + 75 tysięcy pustych linii.
Z artykułu w Niebezpieczniku (a dokładniej testu Cloudflare) wiadomo, że by wydobyć klucz ludzie badajacy potrzebowali 100 tysięcy żądań. Tak wiec jesli atakowanych wezlow w sieci Tor jest 500 (węzłów w sieci jest więcej, ale przyjmijmy że to wystarczy), to regularnie co tydzień (1. może być rozłożone w czasie 2. interesujce certyfikaty się co tydzień zmieniaja ) NSA musiałoby wysłać 50 000 000 żadań Heartbeat do sieci Tor.
Offline
[b]uzytkownikubunt[/b] zacytuję tutaj kolegę mpan, który skomentował to tak:
Czy niełatwo wykraść klucz to trudno powiedzieć. Cloudflare wystawiło 2 serwery, do których wykonano 2.6M zapytań z 2 sukcesami (1.3M/sukces). Liczby wydają się duże, ale zapomnieliście o trzech sprawach:
1. 1.3M potrzeba do wyciągnięcia klucza, a nie do wyciągnięcia jakichkolwiek sensownych danych.
2. Co w przypadku, gdy zamiast wysyłać dużo zapytań do jednego serwera, wysyła się mało zapytań do wielu serwerów? Do masowego zbierania danych jest to też dużo lepsza strategia. 1.3M serwerów przeskanowanych na godzinę i w ciągu roku jest z 9 tysięcy³ kluczyków, a nikt się nie połapie.
3. Lokalizacje uzyskiwane przez testujących były zapewne przypadkowe. Haczyk w tym, że Heartbleed ma drugie dno. OpenSSL nie używa `calloc` do alokacji, tylko własnej puli pamięci kontrolowanej przez kolejkę. De Raadt już swoją tyradę na temat świadomego ominięcia zabezpieczeń przed takimi atakami wygłosił, ale jest jeszcze jedna sprawa: przy [stosunkowo] niewielkiej puli i prostych zależnościach między otrzymywanymi blokami możnaby się pokusić o takie dobranie czasu wykonywania zapytań, żeby uzyskane lokalizacje nie były tak bardzo przypadkowe.[/quote]
źródło: http://niebezpiecznik.pl/post/nsa-korzystalo-z-luki-heartbleed-od-lat-czy-aby-na-pewno-i-czy-to-w-istocie-jest-teraz-nasz-najwiekszy-problem/ ; komentarz użytkownika: mpan
[quote="drelbrown"]Moim zdaniem, różnica, w tej kwestii, pomiędzy zamkniętym i otwartym kodem jest taka, że bardziej prawdopodobne jest wykrycie „niespodzianki” w otwartym. Tylko tyle i aż tyle.[/quote]
Ta afera z ossl tylko pokazuje, że nie ma [b]żadnej różnicy[/b] a rzekome bezpieczeństwo otwartego kodu jest ułudą...Ostatnio edytowany przez menel (2014-04-15 15:47:21)
Offline
@menel
Ściemniasz z tym prawdopodobieństwem.
W programach FLOSS większość dziur jest łapana dosyć wcześnie, większość jednak nie oznacza wszystkich dziur i zawsze.
Z resztą, jak takie same prawdopodobieństwo, to pokaż w Linuxie coś podobnego do tych dziur:
http://niebezpiecznik.pl/post/17-letnia-dziura-w-windows-0day-vdm/
http://niebezpiecznik.pl/post/dziura-w-windows-dll-exe-binary-planting/
Przyjemnej zabawy, ja przez 7 lat na Linuxie nic podobnego nie widziałem i o niczym podobnym (o podobnym ciężarze jakościowym) nie słyszałem.
Największe dziury w Linuxie, jakie widziałem - to ten OpenSSL, dziura w sterach USB - m in usb-caiaq, dziura w Glibc związana z funkcją LD_AUDIT, i kilka drobniejszych podatności, m.in w Apachu, Postfixie, do tego dwa backdoory w serwerach Proftpd i Vsftpd.
Innych dziur były setki, ale żadna nie powstała na etapie projektowania systemu, i żadna nie czekała na załatanie dłużej, niż trzy miesiące.
Ten backdoor w OpenSSL po dostrzeżeniu, został załatany w kilka dni, a nie kilka lat.
Ostatnio edytowany przez Jacekalex (2014-04-15 20:15:01)
Offline
Oczywiście zgadzam się, że dostrzeżone dziury są łatane praktycznie natychmiastowo ale pierw trzeba je dostrzec a tu się okazało, że jednak nikt tego nie dostrzegł przez dwa lata.
Oczywiście łatwiej jest wyłapać bugi we flossie ale nie zapominajmy, że łatwiej także jest takim agencją jak NSA analizować takie oprogramowanie i wyłapywać wszelakie dziury i wykorzystywać je później do własnych celów...
Dlatego nie ma tu najmniejszego znaczenia jeżeli chodzi o bezpieczeństwo czy to będzie zamknięte czy otwarte oprogramowanie, bo szala się wyrównuje w tej kwestii (oczywiście nie biorę pod uwagę jakości danego oprogramowania, mam na myśli tylko aspekt zamkniętego i otwartego)
Ostatnio edytowany przez menel (2014-04-15 22:16:56)
Offline
Idąc tym tokiem rozumowania NSA i tak ma dostęp do źródeł własnościowego softu krypto. Stąd różnica między własnościowym a otwartym jest jedynie taka, ile par oczu patrzy w ten kod ;)
Offline
Idąc tym tokiem rozumowania NSA i tak ma dostęp do źródeł własnościowego softu krypto[/quote]
tego nie wiemy a nawet jeżeli to nie do wszystkiego..
Offline
Ja raczej podejrzewam, że ten numer z OpenSSL to nie NSA, tylko jakiś inny Mukhbarat, stawiam na Ruskich albo prędzej Chińczyków.
Powody następujące:
Nie kto inny, ale Chińczycy już kilka razy wbijali się do serwerów BGP, żeby ruch m.in. FB i Twittera szedł przez Chińskie routery.
SSL utrudniał im skuteczność takich akcji, więc jakoś ten problem musieli rozwiązać.
Rosjanie natomiast mając takich przyjaciół, jak np Snowden, też od dawna próbują wrzucić rządowi amerykańskiemu "jeża w spodnie".
Oba kraje są bardzo aktywne na tym polu, mają też siły, środki
i przede wszystkim pieniądze na takie akcje.
NSA jest o tyle nieprawdopodobne, że jak się ma "przyjaciół" w Google, FB, M$, Intelu, AMD, Nvidii, i setce innych koncernów IT, to po prostu nie trzeba się certolić w podkradanie certów SSL.
Zwłaszcza, że NSA ma wystarczające centrum obliczeniowe, żeby klucz RSA czy DSA 1024-4096 bit (podstawa komunikacji SSL/TLS) złamać w ciągu kilku sekund.
Takiej dziury potrzebowała instytucja o znacznie mniejszych możliwościach operacyjnych, niż amerykanie, ci mają np prism,
i inne zabawki.
Ostatnio edytowany przez Jacekalex (2014-04-15 22:44:55)
Offline
[quote=Jacekalex]Zwłaszcza, że NSA ma wystarczające centrum obliczeniowe, żeby klucz RSA czy DSA 1024-4096 bit (podstawa komunikacji SSL/TLS) złamać w ciągu kilku sekund.[/quote]
[url=https://xkcd.com/285/][citation needed][/url]
Ostatnio edytowany przez enether (2014-04-15 23:10:39)
Offline
Prawdopodobieństwo złamania RSA 4096 bitów jest w moim przekonaniu niemożliwe
Łamanie na tradycyjnym komputerze klucza 20 bitowego trwa 3 sekundy + złamanie klucza jest nieopłacalne. O wiele prościej wrzucić backdoora
Fervi
Offline
Ludzie - z całym szacunkiem, ale właśnie takie mikro błędy pamięciowe są cholernie trudne do wykrycia, gadanie o NSA, ruskich czy marsjanach... no widać że nikt z Was na poważnie nie pisał kodu, zwłaszcza w C/C++, bo chyba każdy kto pisał w tych językach ma setki doświadczeń w stylu podobnym do tego błędu z OpenSSL, myślicie że czemu w nowych językach promuje się AUTOMATYCZNE zarządzanie pamięcią? Ano dlatego że ręczne jest error prone (to że automatyczne ma dużo własnych wad, mnie przekonywać nie trzeba - coś za coś). I już nie takie rzecz się przez pierdoł działy:
http://gadzetomania.pl/2013/02/14/najslynniejsze-bledy-programistyczne-cz-1
Do powyższego dodałbym jeszcze przypadek zestrzelenie Irańskiego samolotu pasażerskiego przez niszczyciel USA, bo zapomniano re-skanować transponderów po namierzeniu celu.
A takich przypadków jest duuuużo więcej - tam też pewnie NSA podkładała bugi co?
Zwłaszcza Ty @Jacekalex (i w tym i w kilku innych wątkach) piszesz tak jakby wszystkie małe błędy były do wyłapania w 5 minut i poprawy w jedną... siądź, napisz coś w czystym C/C++ co ma tyle linijek kodu co OpenSSL i zobaczymy czy błędów pierdółkowatych nie będzie - oj byś się zdziwił ;]
Pozdrawiam.
Offline
W zasadzie tak, ale podobno już jeden programista się przyznał do dodania napisania kawałka kodu biblioteki OpenSSL, zawierającego tą podatność.
[quote="Niebezpiecznik"]Do wprowadzenia fragmentu kodu odpowiadającego za atak Heartbleed do projektu OpenSSL przyznał się niemiecki programista, Robin Seggelmann. Czy został “kupiony” przez NSA? Przecież dodany przez niego kod został przejrzany i zaakceptowany przez innego programistę projektu OpenSSL-a. Obaj zostali “kupieni”? Ja raczej skłaniam się w kierunku tezy, iż był to błąd nieumyślny — jeśli więc NSA miało się o nim dowiedzieć, to albo dzięki przedstawionemu w poprzednim rozdziale własnemu zespołowi, który śledzi kod projektów Open Source w poszukiwaniu błędów, albo poprzez skupowanie 0day’ów z rynku, o czym poniżej. Zanim jednak do tego przejdziemy, waszej uwadze polecam świetny raport na temat sabotażu i złośliwych insiderów-programistów w firmie.[/quote]
Sznurek:
http://niebezpiecznik.pl/post/nsa-korzystalo-z-luki-heartbleed-od-lat-czy-aby-na-pewno-i-czy-to-w-istocie-jest-teraz-nasz-najwiekszy-problem/
Oczywiście to mógł być zwykły błąd, ale mógł też być dodany celowo.
W życiu zawsze są co najmniej dwie możliwości.
Przy okazji, biblioteki szyfrujące klasy OpenSSL piszą nie studenci, tylko chyba absolutna pierwsza liga programistów?
I są starannie sprawdzane i kody, i faktyczne działanie takiego programu czy biblioteki?
Sprawdź, kto i kiedy tutaj zaczął pisać "że to na pewno NSA", na co odpowiedziałem, że na pewno nie wiadomo kto, bo nawet jeśli przekupiono lub zaszantażowano jakiegoś programistę z projektu, to on wcale nie musi wiedzieć, dla kogo pracuje/pracował.
W niektórych zawodach nie zostawia się wszędzie wizytówek. ;)
Rzecz jasna, ten punkt widzenia dotyczy celowego umieszczenia backdoora, a nie przypadkowego błędu.
Ale jak powiadam, póki nie jest dokładnie wyjaśniona sprawa, wszystkie możliwe hipotezy są równoprawne.
Sprawa też nieco przypomina sławną historię implementacji Ipsec w OpenBSD, dlatego hipoteza umyślnego działania nie jest wykluczona.
W każdym razie biblioteki o takim ciężarze gatunkowym, jak OpenSSL są niczym "żona cezara" - poza wszelkim podejrzeniem. ;)
@Huk
I nie przesadzaj, że "każdy błąd w 5 minut" bo to akurat nie jest możliwe, i nie będzie możliwe.
Błąd jest znaleziony, kiedy ktoś go dostrzeże, a to czasami trwa nawet 5 milionów minut albo i więcej.
Fajnie natomiast jest, kiedy po znalezieniu błędu jest szybka reakcja, i pod tym względem do Autorów biblioteki OpenSSL zastrzeżeń nie mam.
To, że szybko się okazało, kto napisał ten felerny kawałek kodu, też dobrze świadczy o projekcie.
I podejrzewam, że gdyby nie chodziło o bibliotekę szyfrującą, jak OpenSSL, NSS czy GnuTLS, to nikt by nie podejrzewał NSA ani żadnego innego "Mukhbaratu".
Po prostu prywatność i powiązane z nią poczucie bezpieczeństwa w internecie są dobrem tak deficytowym, że komentarze w takim przypadku są dość nieuchronne, i nie wszystkie zawsze każdemu muszą się podobać.
Pozdro
;-)
Ostatnio edytowany przez Jacekalex (2014-04-16 07:31:08)
Offline
[quote=Jacekalex]Przy okazji, biblioteki szyfrujące klasy OpenSSL piszą nie studenci, tylko chyba absolutna pierwsza liga programistów?
I są starannie sprawdzane i kody, i faktyczne działanie takiego programu czy biblioteki?
(..)
Fajnie natomiast jest, kiedy po znalezieniu błędu jest szybka reakcja, i pod tym względem do Autorów biblioteki OpenSSL zastrzeżeń nie mam.
To, że szybko się okazało, kto napisał ten felerny kawałek kodu, też dobrze świadczy o projekcie.[/quote]
[url=http://queue.acm.org/detail.cfm?id=2602816]comment from the FreeBSD developer Poul-Henning Kamp[/url]
- The code is a mess
- Documentation is misleading
- The defaults are deceptive
- No central architectural authority
- 6,740 goto statements
- Inline assembly code
- Multiple different coding styles
- Obscure use of macro preprocessors
- Inconsistent naming conventions
- Far too many selections and options
- Unexplained dead code
- Misleading and incoherent comments
(..)
"And it's nobody's fault. No one was ever truly in charge of OpenSSL, it just sort of became the default landfill for prototypes of cryptographic inventions, and since it had everything cryptographic under the sun (somewhere , if you could find out how to use it), it also became the default source of cryptographic functionality. [...] We need a well-designed API, as simple as possible to make it hard for people to use it incorrectly. And we need multiple independent quality implementations of that API, so that if one turns out to be crap, people can switch to a better one in a matter of hours."[/quote]
A co do do szybkiego łatania, to też nie jest dobrze. Od 4 lat w OpenSSL jest odkryta luka bezpieczeństwa powodująca use-after-free race condition i dalej jest nie załatana. Jak ktoś chce załatać, to tutaj [url=http://ftp.openbsd.org/pub/OpenBSD/patches/5.4/common/008_openssl.patch]ma łatkę[/url].
Tutaj najnowszy kod źródłowy OpenSSL, dalej nie załatany: https://git.openssl.org/gitweb/?p=openssl.git;a=blob_plain;f=ssl/s3_pkt.c;hb=HEAD
a tutaj zgłoszenie błędu https://rt.openssl.org/Ticket/Display.html?id=2167&user=guest&pass=guest
Offline
Skoro w takim projekcje wiszą błędy po 4 lata?
To jak tu żyć? pół systemu wymaga tej biblioteki, GNUtls też miewa hardcorowe błędy, w miarę szybko jest łatana biblioteka NSS, ale raczej OpenSSL się na razie zastąpić nie da.
Krótko pisząc, świat nie jest, nie był, i nie będzie idealny. ;)
Czy może OpenSSL staje się "Frankensteinem" podobnym do Xorga, i też czeka na zmiennika, jak Xorg na Waylanda?
I też na świecie jest aż trzech ludzi, którzy wiedzą, jak to wszystko działa?
Ostatnio edytowany przez Jacekalex (2014-04-16 09:13:17)
Offline
"6,740 goto statements"[/quote]
BOŻE! Widzisz i nie grzmisz :/ wypadało by to zaorać i przepisać od zera.Czy może OpenSSL staje się "Frankensteinem" podobnym do Xorga, i też czeka na zmiennika, jak Xorg na Waylanda?
I też na świecie jest aż trzech ludzi, którzy wiedzą, jak to wszystko działa?[/quote]
Z powyższego opisu tak to wygląda :/ niestety stawiam że spora ilość bibliotek "everyday use" tak właśnie od środka wygląda (kojarzysz moja wyliczankę odnośnie tworzenia softu z innego postu? Właśnie do takich wspaniałości to prowadzi ;] ). Inna spraw że w przypadku ClosedSource wcale nie jest lepiej - jakby co niektórzy zobaczyli jak wygląda kod w dużych firmach też by się za głowę złapali ;]Offline
Pamiętam, jak kiedyś wyciekł (chyba w 2011) kod Kasperskiego - Internet Security, i były w nim kawałki kodu pisane w Delphi produkcji jeszcze Borlanda, wersja kodu jakieś 10 lat starsza.
W M$ - nawet w Win7 były kawałki typu copy&paste z Windows 98 - obsługa 16 bitowych aplikacji, co spowodowało chyba największą dziurę w historii systemów operacyjnych, niemal pełnoletnią - 17 lat.
Z KDE5 wywalają wszystkie kawałki QT3support*....
Świat zdecydowanie nie jest idealny, ja jednak wolę takie programy, jak Qmail - czyli rób tylko jedną rzecz, ale rób ją najlepiej, jak się da. ;)
A tu znaki czasów od Mozilli:
du -shm firefox-28.0.source.tar.bz2 129 firefox-28.0.source.tar.bz2
du -shm thunderbird-24.4.0.source.tar.bz2 134 thunderbird-24.4.0.source.tar.bz2
Jak tak dalej pójdzie, to będzie trzeba ddddduuużżżżooo większe dyzie na takie wyczyny szykować. ;)
O prockach i RAMIE nie wspominając.
Aż się boję myśleć, co w takich puchnących jak na drożdżach źródełkach można znaleźć. :/
Ostatnio edytowany przez Jacekalex (2014-04-16 09:56:38)
Offline
Time (s) | Query |
---|---|
0.00009 | SET CHARSET latin2 |
0.00004 | SET NAMES latin2 |
0.00131 | SELECT u.*, g.*, o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='3.138.32.53' WHERE u.id=1 |
0.00101 | REPLACE INTO punbb_online (user_id, ident, logged) VALUES(1, '3.138.32.53', 1732363934) |
0.00043 | SELECT * FROM punbb_online WHERE logged<1732363634 |
0.00056 | SELECT topic_id FROM punbb_posts WHERE id=263094 |
0.00007 | SELECT id FROM punbb_posts WHERE topic_id=25583 ORDER BY posted |
0.00053 | SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=25583 AND t.moved_to IS NULL |
0.00021 | SELECT search_for, replace_with FROM punbb_censoring |
0.00448 | SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=25583 ORDER BY p.id LIMIT 50,25 |
0.00081 | UPDATE punbb_topics SET num_views=num_views+1 WHERE id=25583 |
Total query time: 0.00954 s |